From 38d503bd822aebfae40806c1d8f909cf2a0a20e2 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 15 Sep 2023 09:24:49 -0400 Subject: [PATCH 001/113] Convert docs to mkdocs, material, mermaid (#301) * init mkdocs * init material for mkdocs * add cmu/cert customization * file moves * start formatting * formatting * update authors, ack previous authors * reorganizing content * reorganizing content * reorganizing content * add site deploy action * add mailto link * why isn't workflow dispatch working? * add mkdocs-bibtex * move calculator into site nav * add boxes * add staging branch to deploy_site.yml * remove feature/* from deploy_site.yml * try out workflow to copy to staging * add name to workflow * removing copy on push workflow because YAGNI We can always put it back later if we want to. * add headings, split page * rename files to remove number prefixes * rename files to remove number prefixes * rename files to remove number prefixes * line break each sentence * add headers, boxes * add box, formatting * move methodology and eval into place * move future work * move related systems * split related systems and information sources * move conclusion text to about/index.md * remove obsolete dir * make include page for full cvss v3 tree * update project readme to reflect current directory layout * update project docs readme to reflect current state * move some pieces that are currently obsolete out of the way --- .github/workflows/deploy_site.yml | 61 +++++++ README.md | 44 ++--- .../03_representing_information.md | 167 ------------------ .../04_01_enumerating_stakeholders.md | 33 ---- .../04_02_enumerating_decisions.md | 13 -- doc/md_src_files/04_03_enumerating_actions.md | 129 -------------- .../04_04_items_with_same_priority.md | 8 - .../04_05_risk_tolerance_and_priority.md | 16 -- doc/md_src_files/04_06_scope.md | 67 ------- .../05_00_likely_decision_points.md | 10 -- doc/md_src_files/05_01_exploitation.md | 37 ---- doc/md_src_files/05_02_technical_impact.md | 34 ---- doc/md_src_files/05_03_automatable.md | 38 ---- doc/md_src_files/05_04_value_density.md | 42 ----- doc/md_src_files/05_08_human_impact.md | 90 ---------- .../06_00_coordination_decisions.md | 156 ---------------- .../06_04_publication_decision.md | 50 ------ doc/md_src_files/07_01_supplier_tree.md | 18 -- doc/md_src_files/07_02_deployer_tree.md | 13 -- doc/md_src_files/07_03_coordinator_trees.md | 32 ---- doc/md_src_files/07_05_evidence_gathering.md | 23 --- doc/md_src_files/11_worked_example.md | 37 ---- doc/md_src_files/19_reference_definitions.md | 1 - doc/md_src_files/sources_ssvc.bib | 49 +++-- doc/obsolete/compile-html-citeproc.sh | 24 --- doc/obsolete/compile-pdf.sh | 50 ------ doc/obsolete/compile-v1.sh | 22 --- .../about/acknowledgements.md | 2 - .../about/changelog.md | 0 .../about/contact_us.md | 2 +- docs/about/contributing.md | 1 + .../about/copyright.md | 0 .../15_conclusion.md => docs/about/index.md | 12 +- docs/assets/cert_seal.svg | 1 + .../howto/asset_management.md | 22 ++- .../howto/communicating_results.md | 0 docs/howto/coordination_decisions.md | 56 ++++++ docs/howto/coordinator_publish_tree.md | 124 +++++++++++++ docs/howto/coordinator_trees.md | 17 ++ docs/howto/deployer_tree.md | 13 ++ docs/howto/evidence_gathering.md | 84 +++++++++ docs/howto/index.md | 25 +++ .../howto/prioritization.md | 0 docs/howto/publication_decision.md | 36 ++++ docs/howto/supplier_tree.md | 17 ++ .../howto/tree_customization.md | 0 docs/index.md | 7 + docs/javascripts/mathjax.js | 16 ++ docs/javascripts/tablesort.js | 6 + .../pdf}/ssvc_2_coord-publish.pdf | Bin .../pdf}/ssvc_2_coord-triage.pdf | Bin .../pdf}/ssvc_2_deployer_SeEUMss.pdf | Bin .../graphics => docs/pdf}/ssvc_2_supplier.pdf | Bin docs/reference/decision_points/automatable.md | 80 +++++++++ .../reference/decision_points/exploitation.md | 40 +++++ .../decision_points/likely_decision_points.md | 27 +++ .../decision_points/mission_impact.md | 21 +-- .../decision_points/public_value_added.md | 18 ++ .../decision_points/report_credibility.md | 22 +++ .../decision_points/report_public.md | 9 + .../decision_points/safety_impact.md | 60 +++---- .../decision_points/supplier_cardinality.md | 8 + .../decision_points/supplier_contacted.md | 14 ++ .../decision_points/supplier_engagement.md | 9 + .../decision_points/supplier_involvement.md | 10 ++ .../decision_points/system_exposure.md | 18 +- .../decision_points/technical_impact.md | 34 ++++ .../decision_points/value_density.md | 46 +++++ docs/reference/index.md | 12 ++ .../ssvc-calc}/CISA-Coordinator.json | 0 .../ssvc-calc}/Coordinator-Publish.json | 0 .../ssvc-calc}/Coordinator-Triage.json | 0 {ssvc-calc => docs/ssvc-calc}/Deployer.json | 0 {ssvc-calc => docs/ssvc-calc}/README.md | 0 docs/ssvc-calc/SSVC_Computed.schema.json | 1 + docs/ssvc-calc/SSVC_Provision.schema.json | 1 + {ssvc-calc => docs/ssvc-calc}/Supplier.json | 0 {ssvc-calc => docs/ssvc-calc}/cmu-logo.png | Bin {ssvc-calc => docs/ssvc-calc}/css.css | 0 .../ssvc-calc}/icons8-copy-60.png | Bin .../ssvc-calc}/icons8-copy-link-48.png | Bin {ssvc-calc => docs/ssvc-calc}/index.html | 4 +- {ssvc-calc => docs/ssvc-calc}/main.css | 0 {ssvc-calc => docs/ssvc-calc}/moon_icon.png | Bin {ssvc-calc => docs/ssvc-calc}/sample-ssvc.txt | 0 {ssvc-calc => docs/ssvc-calc}/ssvc.js | 0 {ssvc-calc => docs/ssvc-calc}/ungraph.js | 0 docs/stylesheets/extra.css | 5 + docs/topics/compound_decision_points.md | 15 ++ docs/topics/credibility_indicators.md | 66 +++++++ docs/topics/cvss_full_tree.md | 5 + docs/topics/decision_trees.md | 55 ++++++ docs/topics/enumerating_actions.md | 91 ++++++++++ docs/topics/enumerating_decisions.md | 27 +++ docs/topics/enumerating_stakeholders.md | 40 +++++ .../evaluation/development_methodology.md | 4 +- .../evaluation/evaluation_of_draft_trees.md | 0 docs/topics/formalization_options.md | 48 +++++ .../topics/future_work.md | 2 - docs/topics/human_impact.md | 51 ++++++ docs/topics/information_sources.md | 91 ++++++++++ .../topics/introduction.md | 60 ++++++- docs/topics/items_with_same_priority.md | 33 ++++ .../topics/limitations.md | 39 ++-- docs/topics/public_safety_impact.md | 18 ++ .../topics/related_systems.md | 70 -------- docs/topics/representing_information.md | 91 ++++++++++ docs/topics/risk_tolerance_and_priority.md | 37 ++++ docs/topics/scope.md | 104 +++++++++++ .../topics/state_of_practice.md | 0 docs/topics/units_of_work.md | 96 ++++++++++ .../topics/utility.md | 35 ++-- .../vulnerability_management_decisions.md | 0 docs/topics/worked_example.md | 86 +++++++++ docs/tutorials/index.md | 27 +++ index.html | 2 +- mkdocs.yml | 154 ++++++++++++++++ {doc => obsolete}/Makefile | 0 {doc => obsolete}/emoji-replacements.sed | 0 .../pandoc_html_pdf.yaml | 0 {doc => obsolete}/pdf-styling.yaml | 0 {doc => project_docs}/README.md | 125 +++++++++---- requirements.txt | 6 + ssvc-calc/SSVC_Computed.schema.json | 1 - ssvc-calc/SSVC_Provision.schema.json | 1 - 125 files changed, 2257 insertions(+), 1367 deletions(-) create mode 100644 .github/workflows/deploy_site.yml delete mode 100644 doc/md_src_files/03_representing_information.md delete mode 100644 doc/md_src_files/04_01_enumerating_stakeholders.md delete mode 100644 doc/md_src_files/04_02_enumerating_decisions.md delete mode 100644 doc/md_src_files/04_03_enumerating_actions.md delete mode 100644 doc/md_src_files/04_04_items_with_same_priority.md delete mode 100644 doc/md_src_files/04_05_risk_tolerance_and_priority.md delete mode 100644 doc/md_src_files/04_06_scope.md delete mode 100644 doc/md_src_files/05_00_likely_decision_points.md delete mode 100644 doc/md_src_files/05_01_exploitation.md delete mode 100644 doc/md_src_files/05_02_technical_impact.md delete mode 100644 doc/md_src_files/05_03_automatable.md delete mode 100644 doc/md_src_files/05_04_value_density.md delete mode 100644 doc/md_src_files/05_08_human_impact.md delete mode 100644 doc/md_src_files/06_00_coordination_decisions.md delete mode 100644 doc/md_src_files/06_04_publication_decision.md delete mode 100644 doc/md_src_files/07_01_supplier_tree.md delete mode 100644 doc/md_src_files/07_02_deployer_tree.md delete mode 100644 doc/md_src_files/07_03_coordinator_trees.md delete mode 100644 doc/md_src_files/07_05_evidence_gathering.md delete mode 100644 doc/md_src_files/11_worked_example.md delete mode 100644 doc/md_src_files/19_reference_definitions.md delete mode 100755 doc/obsolete/compile-html-citeproc.sh delete mode 100755 doc/obsolete/compile-pdf.sh delete mode 100755 doc/obsolete/compile-v1.sh rename doc/md_src_files/16_acknowledgements.md => docs/about/acknowledgements.md (99%) rename doc/md_src_files/09_changelog.md => docs/about/changelog.md (100%) rename doc/md_src_files/17_contact_us.md => docs/about/contact_us.md (77%) create mode 100644 docs/about/contributing.md rename doc/md_src_files/18_copyright.md => docs/about/copyright.md (100%) rename doc/md_src_files/15_conclusion.md => docs/about/index.md (84%) create mode 100644 docs/assets/cert_seal.svg rename doc/md_src_files/07_06_asset_management.md => docs/howto/asset_management.md (64%) rename doc/md_src_files/08_communicating_results.md => docs/howto/communicating_results.md (100%) create mode 100644 docs/howto/coordination_decisions.md create mode 100644 docs/howto/coordinator_publish_tree.md create mode 100644 docs/howto/coordinator_trees.md create mode 100644 docs/howto/deployer_tree.md create mode 100644 docs/howto/evidence_gathering.md create mode 100644 docs/howto/index.md rename doc/md_src_files/07_00_prioritization.md => docs/howto/prioritization.md (100%) create mode 100644 docs/howto/publication_decision.md create mode 100644 docs/howto/supplier_tree.md rename doc/md_src_files/07_04_tree_customization.md => docs/howto/tree_customization.md (100%) create mode 100644 docs/index.md create mode 100644 docs/javascripts/mathjax.js create mode 100644 docs/javascripts/tablesort.js rename {doc/graphics => docs/pdf}/ssvc_2_coord-publish.pdf (100%) rename {doc/graphics => docs/pdf}/ssvc_2_coord-triage.pdf (100%) rename {doc/graphics => docs/pdf}/ssvc_2_deployer_SeEUMss.pdf (100%) rename {doc/graphics => docs/pdf}/ssvc_2_supplier.pdf (100%) create mode 100644 docs/reference/decision_points/automatable.md create mode 100644 docs/reference/decision_points/exploitation.md create mode 100644 docs/reference/decision_points/likely_decision_points.md rename doc/md_src_files/05_07_mission_impact.md => docs/reference/decision_points/mission_impact.md (79%) create mode 100644 docs/reference/decision_points/public_value_added.md create mode 100644 docs/reference/decision_points/report_credibility.md create mode 100644 docs/reference/decision_points/report_public.md rename doc/md_src_files/05_06_safety_impact.md => docs/reference/decision_points/safety_impact.md (78%) create mode 100644 docs/reference/decision_points/supplier_cardinality.md create mode 100644 docs/reference/decision_points/supplier_contacted.md create mode 100644 docs/reference/decision_points/supplier_engagement.md create mode 100644 docs/reference/decision_points/supplier_involvement.md rename doc/md_src_files/05_09_system_exposure.md => docs/reference/decision_points/system_exposure.md (78%) create mode 100644 docs/reference/decision_points/technical_impact.md create mode 100644 docs/reference/decision_points/value_density.md create mode 100644 docs/reference/index.md rename {ssvc-calc => docs/ssvc-calc}/CISA-Coordinator.json (100%) rename {ssvc-calc => docs/ssvc-calc}/Coordinator-Publish.json (100%) rename {ssvc-calc => docs/ssvc-calc}/Coordinator-Triage.json (100%) rename {ssvc-calc => docs/ssvc-calc}/Deployer.json (100%) rename {ssvc-calc => docs/ssvc-calc}/README.md (100%) create mode 120000 docs/ssvc-calc/SSVC_Computed.schema.json create mode 120000 docs/ssvc-calc/SSVC_Provision.schema.json rename {ssvc-calc => docs/ssvc-calc}/Supplier.json (100%) rename {ssvc-calc => docs/ssvc-calc}/cmu-logo.png (100%) rename {ssvc-calc => docs/ssvc-calc}/css.css (100%) rename {ssvc-calc => docs/ssvc-calc}/icons8-copy-60.png (100%) rename {ssvc-calc => docs/ssvc-calc}/icons8-copy-link-48.png (100%) rename {ssvc-calc => docs/ssvc-calc}/index.html (99%) rename {ssvc-calc => docs/ssvc-calc}/main.css (100%) rename {ssvc-calc => docs/ssvc-calc}/moon_icon.png (100%) rename {ssvc-calc => docs/ssvc-calc}/sample-ssvc.txt (100%) rename {ssvc-calc => docs/ssvc-calc}/ssvc.js (100%) rename {ssvc-calc => docs/ssvc-calc}/ungraph.js (100%) create mode 100644 docs/stylesheets/extra.css create mode 100644 docs/topics/compound_decision_points.md create mode 100644 docs/topics/credibility_indicators.md create mode 100644 docs/topics/cvss_full_tree.md create mode 100644 docs/topics/decision_trees.md create mode 100644 docs/topics/enumerating_actions.md create mode 100644 docs/topics/enumerating_decisions.md create mode 100644 docs/topics/enumerating_stakeholders.md rename doc/md_src_files/07_07_development_methodology.md => docs/topics/evaluation/development_methodology.md (84%) rename doc/md_src_files/10_evaluation_of_draft_trees.md => docs/topics/evaluation/evaluation_of_draft_trees.md (100%) create mode 100644 docs/topics/formalization_options.md rename doc/md_src_files/13_future_work.md => docs/topics/future_work.md (99%) create mode 100644 docs/topics/human_impact.md create mode 100644 docs/topics/information_sources.md rename doc/md_src_files/01_introduction.md => docs/topics/introduction.md (59%) create mode 100644 docs/topics/items_with_same_priority.md rename doc/md_src_files/14_limitations.md => docs/topics/limitations.md (51%) create mode 100644 docs/topics/public_safety_impact.md rename doc/md_src_files/12_related_systems.md => docs/topics/related_systems.md (55%) create mode 100644 docs/topics/representing_information.md create mode 100644 docs/topics/risk_tolerance_and_priority.md create mode 100644 docs/topics/scope.md rename doc/md_src_files/02_state_of_practice.md => docs/topics/state_of_practice.md (100%) create mode 100644 docs/topics/units_of_work.md rename doc/md_src_files/05_05_utility.md => docs/topics/utility.md (78%) rename doc/md_src_files/04_00_vulnerability_management_decisions.md => docs/topics/vulnerability_management_decisions.md (100%) create mode 100644 docs/topics/worked_example.md create mode 100644 docs/tutorials/index.md create mode 100644 mkdocs.yml rename {doc => obsolete}/Makefile (100%) rename {doc => obsolete}/emoji-replacements.sed (100%) rename {.github/workflows => obsolete}/pandoc_html_pdf.yaml (100%) rename {doc => obsolete}/pdf-styling.yaml (100%) rename {doc => project_docs}/README.md (54%) create mode 100644 requirements.txt delete mode 120000 ssvc-calc/SSVC_Computed.schema.json delete mode 120000 ssvc-calc/SSVC_Provision.schema.json diff --git a/.github/workflows/deploy_site.yml b/.github/workflows/deploy_site.yml new file mode 100644 index 00000000..6f52da32 --- /dev/null +++ b/.github/workflows/deploy_site.yml @@ -0,0 +1,61 @@ +# Simple workflow for deploying static content to GitHub Pages +name: Deploy static content to Pages + +on: + # Allows you to run this workflow manually from the Actions tab + workflow_dispatch: + + # Runs on pushes targeting the default branch + push: + branches: [main, staging] + + +# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages +permissions: + contents: read + pages: write + id-token: write + +# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. +# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. +concurrency: + group: "pages" + cancel-in-progress: false + +jobs: + # Single deploy job since we're just deploying + deploy: + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v3 + + - name: Set up Python + uses: actions/setup-python@v4 + with: + python-version: '3.10' + + - name: Install dependencies + run: | + python -m pip install --upgrade pip + python -m pip install -r requirements.txt + + - name: Setup Pages + uses: actions/configure-pages@v3 + + - name: Build Site + run: | + mkdocs build --verbose --clean --config-file mkdocs.yml + + - name: Upload artifact + uses: actions/upload-pages-artifact@v2 + with: + # Upload entire repository + path: 'site' + + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v2 diff --git a/README.md b/README.md index 42e150a4..de74d2ca 100644 --- a/README.md +++ b/README.md @@ -10,19 +10,27 @@ SSVC aims to avoid one-size-fits-all solutions in favor of a modular decision-ma SSVC is mostly conceptual tools for vulnerability management. These conceptual tools (how to make decisions, what should go into a decision, how to document and communicate decisions clearly, etc.) are described here. -## `/doc/*` +## `/docs/*` + +Raw markdown and graphics files used to build the SSVC documentation website. +See [`project_docs/README.md`](project_docs/README.md) for more info. + + +### `/docs/ssvc-calc` + +Directory with SSVC calculator using D3 graph. +See [`ssvc-calc/README.md`](docs/ssvc-calc/README.md) for more info. + +A demo version of `ssvc-calc` can be found at https://certcc.github.io/SSVC/ssvc-calc/ -Raw markdown and graphics files used to build document artifacts. -See [`doc/README.md`](doc/README.md) for -more info. ## `/draft/*` -Generated drafts of reports. Usually these will be recent versions of the main document in both `pdf` and `html` formats. -At the moment, these are manually generated using the `make all` target from within `/doc`. -For the absolute latest version generated from the most recent commit on the `main` branch, -see the `output.zip` file artifact attached to the most recent run of the -[pandoc_html_pdf.yaml](https://github.com/CERTCC/SSVC/actions/workflows/pandoc_html_pdf.yaml) workflow. +Generated drafts of reports. +Up through SSVC v2.1.1, these were recent versions of the main document in both `pdf` and `html` formats. + +With the recent conversion from the SSVC documentation from `pdf`-document orientation to a website orientation, +we are no longer generating `pdf` versions of the main document. ## `/pdfs/*.pdf` @@ -31,15 +39,15 @@ Static versions of previously issued reports are stored in this directory. ## `/data/*.csv` The data folder contains detailed data files that define suggested prioritization results based on each combination of information on a vulnerability work item. -Also included in data are the lookup tables as csv files which `ssvc.py` -reads in. -These files define one row per possible path through the trees as -described in the paper. -The tools in the `src` folder provide an interface to work with these data files. +Also included in data are the lookup tables as csv files which `ssvc.py` reads in. +These files define one row per possible path through the trees as described in the documentation. Customizing the "outcome" column in this csv is the primary recommended way that stakehodlers might adapt SSVC to their environment. +## `/src/*` + +The tools in the `src` folder provide an interface to work with these data files. -## `src/ssvc.py` +### `src/ssvc.py` A basic Python module for interacting with the SSVC trees. `ssvc.py` has two methods: `applier_tree()` and `developer_tree()` @@ -48,12 +56,6 @@ The two methods just loop through their respective lookup tables until they hit a match, then return the outcome. Maybe not the best implementation, but it worked well enough for what was needed at the time. -## `ssvc-calc` - -Directory with SSVC calculator using D3 graph. -See [`ssvc-calc/README.md`](ssvc-calc/README.md) for more info. - -A demo version of `ssvc-calc` can be found at https://certcc.github.io/SSVC/ssvc-calc/ ## Citing SSVC diff --git a/doc/md_src_files/03_representing_information.md b/doc/md_src_files/03_representing_information.md deleted file mode 100644 index 54144f81..00000000 --- a/doc/md_src_files/03_representing_information.md +++ /dev/null @@ -1,167 +0,0 @@ - - -# Representing Information for Decisions About Vulnerabilities - -We propose that decisions about vulnerabilities—rather than their severity—are a more useful approach. -Our design goals for the decision-making process are to -- clearly define whose decisions are involved -- properly use evidentiary categories -- be based on reliably available evidence -- be transparent -- be explainable - -Our inspiration and justification for these design goals are that they are the features of a satisfactory scientific enterprise [@spring2017why] adapted to the vulnerability management problem. - -To consider decisions about managing the vulnerability rather than just its technical severity, one must be clear about whose decisions are involved. -Organizations that produce patches and fix software clearly have different decisions to make than those that deploy patches or other security mitigations. -For example, organizations in the aviation industry have different priorities than organizations that make word processors. -These differences indicate a requirement: any formalism must adequately capture the different decisions and priorities exhibited by different groups of stakeholders. -As a usability requirement, the number of stakeholder groups needs to be small enough to be manageable, both by those issuing scores and those seeking them. - -The goal of adequacy is more appropriate than optimality. -Our search process need not be exhaustive; we are satisficing rather than optimizing [@simon1996sciences]. -Finding any system that meets all of the desired criteria is enough. - -Decisions are not numbers. -They are qualitative actions that an organization can take. -In many cases, numerical values can be directly converted to qualitative decisions. -For example, if your child’s temperature is 105°F (40.5°C), you decide to go to the hospital immediately. -Conversion from numerical to qualitative values can be complicated by measurement uncertainty and the design of the metrics. -For example, CVSS scores were designed to be accurate with +/- 0.5 points of the given score [@cvss_v3-1, section 7.5]. -Therefore, under a Gaussian error distribution, 8.9 is really 60\% high and 40\% critical since the recommended dividing line is 9.0. -SSVC decisions should be distinct and crisp, without such statistical overlaps. - -We avoid numerical representations for either inputs or outputs of a vulnerability management decision process. -Quantified metrics are more useful when (1) data for decision making is available, and (2) the stakeholders agree on how to measure. -Vulnerability management does not yet meet either criterion. -Furthermore, it is not clear to what extent measurements about a vulnerability can be informative about other vulnerabilities. -Each vulnerability has a potentially unique relationship to the socio-technical system in which it exists, including the Internet. - -Vulnerability management decisions are often contextual: given what is known at the time, the decision is to do X. -But what is known can change over time, which can and should influence the decision. -The context of the vulnerability, and the systems it impacts, are inextricably linked to managing it. -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](information-changes-over-time). - -We make the deliberation process as clear as is practical; therefore, we risk belaboring some points to ensure our assumptions and reasoning are explicit. -Transparency should improve trust in the results. - -Finally, any result of a decision-making process should be **explainable** -Explainable is defined and used with its common meaning, not as it is used in the research area of explainable artificial intelligence. -An explanation should make the process intelligible to an interested, competent, non-expert person. -There are at least two reasons common explainability is important: (1) for troubleshooting and error correction and (2) for justifying proposed decisions. - -To summarize, the following are our design goals for a vulnerability -management process: - - - Outputs are decisions. - - - Pluralistic recommendations are made among a manageable number of - stakeholder groups. - - - Inputs are qualitative. - - - Outputs are qualitative, and there are no (unjustified) shifts to - quantitative calculations. - - - Process justification is transparent. - - - Results are explainable. - -## 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. -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. -We focus on highlighting why some common options or suggestions do not meet the above design goals. -We argue that decision trees are a satisfactory formalism. - -We rule out many quantitative options, such as anything involving statistical regression techniques or Bayesian belief propagation. -Most machine learning (ML) algorithms are also not suitable because they are both unexplainable (in the common sense meaning) and quantitative. -Random forest algorithms may appear in scope since each individual decision tree can be traced and the decisions explained [@russell2011artificial]. -However, they are not transparent enough to simply know how the available decision trees are created or mutated and why a certain set of them works better. -In any case, random forests are necessary only when decision trees get too complicated for humans to manage. -We demonstrate below that in vulnerability management, useful decision trees are small enough for humans to manage. - -Logics are generally better suited for capturing qualitative decisions. -Boolean first-order logic is the “usual” logic—with material implication (if/then), negation, existential quantification, and predicates. -For example, in program verification, satisfiability problem (SAT) and satisfiability modulo theories (SMT) solvers are used to automate decisions about when some condition holds or whether software contains a certain kind of flaw. -While the explanations provided by logical tools are accessible to experts, non-experts may struggle. -Under special conditions, logical formulae representing decisions about categorization based on exclusive-or conditions can be more compactly and intelligibly represented as a decision tree. - -Decision trees are used differently in operations research than in ML. -In ML, decision trees are used as a predictive model to classify a target variable based on dependent variables. -In operations research and decision analysis, a decision tree is a tool that is used to document a human process. -In decision analysis, analysts “frequently use specialized tools, such as decision tree techniques, to evaluate uncertain situations” [@howard1983readings, viii]. -We use decision trees in the tradition of decision analysis, not ML. - -Table: How Vulnerability Prioritization Options Meet the Design Goals - -| | **Outputs are Decisions** | **Pluralistic** | **Qualitative Inputs** | **Qualitative Outputs** | **Transparent** | **Explainable** | -| :--- | :-: | :-: | :-: | :-: | :-: | :-: | -| *Parametric Regression* | :x: | :x: | :white_check_mark: | :x: | :x: | :white_check_mark: | -| *CVSS v3.0* | :x: | :x: | :white_check_mark: | :x: | :x: | :x: | -| *Bayesian Belief Networks* | :x: | Maybe | :x: | :x: | :white_check_mark: | :white_check_mark: | -| *Neural Networks* | :x: | :x: | :x: | :x: | :x: | :x: | -| *Random Forest* | :white_check_mark: | :white_check_mark: | :white_check_mark: | Maybe | :x: | Maybe | -| *Other ML* | :x: | Maybe | :x: | :x: | :x: | :x: | -| *Boolean First Order Logics* | Maybe | Maybe | :white_check_mark: | :white_check_mark: | :white_check_mark: | Maybe | -| *Decision Trees* | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | - -## Decision Trees - -A decision tree is an acyclic structure where nodes represent aspects of the decision or relevant properties and branches represent possible options for each aspect or property. -Each decision point can have two or more options. - -Decision trees can be used to meet all of the design goals, even plural recommendations and transparent tree-construction processes. -Decision trees support plural recommendations because a separate tree can represent each stakeholder group. -The opportunity for transparency surfaces immediately: any deviation among the decision trees for different stakeholder groups should have a documented reason—supported by public evidence when possible—for the deviation. -Transparency may be difficult to achieve, since each node in the tree and each of the values need to be explained and justified, but this cost is paid infrequently. - -There has been limited but positive use of decision trees in vulnerability management. -For example, Vulnerability Response Decision Assistance (VRDA) studies how to make decisions about how to respond to vulnerability reports [@manion2009vrda]. -This paper continues roughly in the vein of such work to construct multiple decision trees for prioritization within the vulnerability management process. - -## Representation choices - -A decision tree can represent the same content in different ways. -Since a decision tree is a representation of logical relationships between qualitative variables, the equivalent content can be represented in other formats as well. -The R package [data.tree](https://cran.r-project.org/web/packages/data.tree/data.tree.pdf) has a variety of both internal representations and visualizations. - -For data input, we elected to keep SSVC simpler than R, and just use a CSV (or other fixed-delimiter separated file) as canonical data input. -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)). -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. -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. - -The tree visualization options are more diverse. -We provide an example format, and codified it in [src/SSVC_csv-to-latex.py](https://github.com/CERTCC/SSVC/tree/main/src). -Why have we gone to this trouble when (for example) the R data.tree package has a handy print-to-ASCII function? -Because this function produces output like the following: -``` -1 start -2 ¦--AV:N -3 ¦ ¦--AC:L -4 ¦ ¦ ¦--PR:N -... -31 ¦ ¦ ¦ ¦ ¦ ¦ ¦--A:L Medium -32 ¦ ¦ ¦ ¦ ¦ ¦ °--A:N Medium -33 ¦ ¦ ¦ ¦ ¦ °--C:N -34 ¦ ¦ ¦ ¦ ¦ ¦--I:H -35 ¦ ¦ ¦ ¦ ¦ ¦ ¦--A:H Critical -``` - -This sample is a snippet of the CVSS version 3.0 base scoring algorithm represented as a decision tree. -The full tree can be found in [doc/graphics/cvss_tree_severity-score.txt](https://github.com/CERTCC/SSVC/tree/main/doc/graphics). -This tree representation is functional, but not as flexible or aesthetic as might be hoped. -The visualizations provided by R are geared towards analysis of decision trees in a random forest ML model, rather than operations-research type trees. diff --git a/doc/md_src_files/04_01_enumerating_stakeholders.md b/doc/md_src_files/04_01_enumerating_stakeholders.md deleted file mode 100644 index 8e895f4e..00000000 --- a/doc/md_src_files/04_01_enumerating_stakeholders.md +++ /dev/null @@ -1,33 +0,0 @@ -## Enumerating Stakeholders - -Stakeholders in vulnerability management can be identified within multiple independent axes. -For example, they can be identified by their responsibility: whether the group *supplies*, *deploys*, or *coordinates* remediation actions. -Depending what task a team is performing in a supply chain, the team may be considered a supplier, deployer, or a coordinator. -Therefore, one organization may have teams that take on different roles. -For example, an organization that develops and uses its own software might delegate the supplier role to its development team and the deployer role to its IT operations team. -On the other hand, organizations using a DevOps approach to providing services might have a single group responsible for both the supplier and deployer roles. -Organizations may also be distinguished by the type of industry sector. While it might be useful to enumerate all the sectors of the economy, we propose to draft decision points that include those from multiple important sectors. -For example, we have safety-related questions in the decision path for all suppliers and deployers. -The decision will be assessed whether or not the stakeholder is in a safety-critical sector. - -The choice not to segregate the decisions by sector is reinforced by the fact that any given software system might be used by different sectors. -It is less likely that one organization has multiple responsibilities within the vulnerability management process. -Even if there is overlap within an organization, the two responsibilities are often located in distinct business units with distinct decision-making processes. -We can treat the responsibilities as non-overlapping, and, therefore, we can build two decision trees—one for each of the “patch supplier” and “patch deployer” responsibilities in the vulnerability management process. -We leave “coordinating patches” as future work. -Each of these trees will have different decision points that they take to arrive at a decision about a given unit of work. - - -The next two sections describe the decision space and the relevant decision points that we propose for these two responsibilities within the vulnerability management process. - -The target audience for this paper is professional staff responsible for making decisions about information systems. -This audience encompasses a broad class of professionals, including suppliers, system maintainers, and administrators of many types. -It also includes other roles, such as risk managers, technical managers, and incident responders. -Although every layperson who owns a computing device makes decisions about managing it, they are not the target audience. -The following decision system may help such laypeople, but we do not intend it to be used by that audience. - -While C-level executives and public policy professionals often make, shape, or incentivize decisions about managing information systems, they are not the target audience, either. -To the extent that decision trees for vulnerability management help higher level policy decisions, we believe the best way to help policy makers is by making technical decisions more transparent and explainable. -Policy makers may see indirect benefits, but they are not our primary audience and we are not designing an approach for them directly. - - diff --git a/doc/md_src_files/04_02_enumerating_decisions.md b/doc/md_src_files/04_02_enumerating_decisions.md deleted file mode 100644 index 0d512b6d..00000000 --- a/doc/md_src_files/04_02_enumerating_decisions.md +++ /dev/null @@ -1,13 +0,0 @@ -## Enumerating Decisions - -Stakeholders with different responsibilities in vulnerability management have very different decisions to make. -This section focuses on the differences among organizations based on their vulnerability management responsibilities. -Some decision makers may have different responsibilities in relation to different software. For example, an Android app developer is a developer of the app, but is a deployer for any changes to the Android OS API. -This situation is true for libraries in general. -A web browser developer makes decisions about applying patches to DNS lookup libraries and transport layer security (TLS) libraries. -A video game developer makes decisions about applying patches released to the Unreal Engine. -A medical device developer makes decisions about applying patches to the Linux kernel. The list goes on. -Alternatively, one might view applying patches as including some development and distribution of the updated product. -Or one might take the converse view, that development includes updating libraries. -Either way, in each of these examples (mobile device apps, web browsers, video games, medical devices), we recommend that the professionals making genuine decisions do three things: (1) identify the decisions explicitly, (2) describe how they view their role(s), and (3) identify which software projects their decision relates to. -If their decisions are explicit, then the decision makers can use the recommendations from this document that are relevant to them. diff --git a/doc/md_src_files/04_03_enumerating_actions.md b/doc/md_src_files/04_03_enumerating_actions.md deleted file mode 100644 index 6bfe7fb6..00000000 --- a/doc/md_src_files/04_03_enumerating_actions.md +++ /dev/null @@ -1,129 +0,0 @@ -## Enumerating Vulnerability Management Actions -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. -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. - -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 - -- 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) - -Without belaboring the point, the above 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. - -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 ### - -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**. -The relationship between SSVC and asset management is discussed further in [Relationship to asset management](#relationship-to-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 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 ### - -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. - -### 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). - -Table: Proposed Meaning for Supplier Priority Outcomes - -| 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. [Table 3](#table-deployer-outcomes) 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. - -However, these mitigation techniques will not always work. For example, the implementation of a firewall or IDS rule to mitigate [*System Exposure*](#system-exposure) 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 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*](#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. - -As opposed to mitigation, applying a remediation finishes an SSVC analysis of a deployed system. -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. - - -Table: Proposed Meaning for Deployer Priority Outcomes - -| 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]. -The second decision is whether to publish information about a vulnerability. -We omit a table for this decision because the options are *do not publish* or *publish*. - -Table: Proposed Coordinator Triage Priority Outcomes - -| 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. | - diff --git a/doc/md_src_files/04_04_items_with_same_priority.md b/doc/md_src_files/04_04_items_with_same_priority.md deleted file mode 100644 index 73d4c5ed..00000000 --- a/doc/md_src_files/04_04_items_with_same_priority.md +++ /dev/null @@ -1,8 +0,0 @@ -## Items With the Same Priority - -Within each setting, the decisions are a kind of equivalence class for priority. That is, if an organization must deploy patches for three vulnerabilities, and if these vulnerabilities are all assigned the *scheduled* priority, then the organization can decide which to deploy first. The priority is equivalent. This approach may feel uncomfortable since CVSS gives the appearance of a finer grained priority. CVSS appears to say, “Not just 4.0 to 6.9 is ‘medium’ severity, but 4.6 is more severe than 4.5.” However, as discussed previously (see page 4), CVSS is designed to be accurate only within +/- 0.5, and, in practice, is scored with errors of around +/- 1.5 to 2.5 [@allodi2018effect, see Figure 1]. An error of this magnitude is enough to make all of the “normal” range from 4.0 to 6.9 equivalent, because 5.5 +/- 1.5 is the range 4.0 to 7.0. Our proposal is an improvement over this approach. CVSS errors often cross decision boundaries; in other words, the error range often includes the transition between “high” and “critical” or “medium.” Since our approach keeps the decisions qualitatively defined, this fuzziness does not -affect the results. - -Returning to the example of an organization with three vulnerabilities to remediate that were assigned *scheduled* priority, in SSVC, they can be patched in any order. This is an improvement over CVSS, since based on the scoring errors, CVSS was essentially just giving random fine-grained priorities within qualitative categories anyway. With our system, organizations can be more deliberate about conveniently organizing work that is of equivalent priority. - - diff --git a/doc/md_src_files/04_05_risk_tolerance_and_priority.md b/doc/md_src_files/04_05_risk_tolerance_and_priority.md deleted file mode 100644 index 5e30f207..00000000 --- a/doc/md_src_files/04_05_risk_tolerance_and_priority.md +++ /dev/null @@ -1,16 +0,0 @@ -## Risk Tolerance and Response Priority - -SSVC enables stakeholders to balance and manage their risks themselves. -We follow the risk management vocabulary from [@ISO73] and define risk as “effect of uncertainty on objectives;” see [@ISO73] for notes on the terms in the definition. -A successful vulnerability management practice must balance at least two risks: - -1. Change risk: the potential costs of deploying remediation, which include testing and deployment in addition to any problems that could arise from making changes to production systems. -2. Vulnerability risk: the potential costs of incidents resulting from exploitation of vulnerable systems - -To place these risks in context, we follow the SEI's Taxonomy of Operational Cyber Security Risks [@cebula2010taxonomy]. Change risk can be characterized as a combination of Class 2 and/or Class 3 risks. Class 2: Systems and Technology Failures includes hardware, software, and systems risks. Class 3: Failed Internal Processes can arise from process design, process execution, process controls, or supporting processes. Meanwhile, vulnerability risk falls into Subclass 1.2: Actions of People: Deliberate. - -In developing the decision trees in this document, we had in mind stakeholders with a moderate tolerance for risk. The resulting trees reflect that assumption. Organizations may of course be more or less conservative in their own vulnerability management practices, and we cannot presume to determine how an organization should balance their risk. - -We therefore remind our readers that the labels on the trees (defer, immediate, etc.) can and should be customized to suit the needs of individual stakeholders wherever necessary and appropriate. For example, an organization with a high aversion to change risk might choose to accept more vulnerability risk by lowering the overall response labels for many branches in the trees, resulting in fewer vulnerabilities attaining the most urgent response. On the other hand, an organization with a high aversion to vulnerability risk could elevate the priority of many branches to ensure fixes are deployed quickly. - - diff --git a/doc/md_src_files/04_06_scope.md b/doc/md_src_files/04_06_scope.md deleted file mode 100644 index 77cb83d8..00000000 --- a/doc/md_src_files/04_06_scope.md +++ /dev/null @@ -1,67 +0,0 @@ -## Scope - -Scope is an important variable in the answers of these decision points. -It has at least three aspects. -The first is how the boundaries of the affected system are set. -The second is whose security policy is relevant. -The third is how far forward in time or causal steps one reasons about effects and harms. -We put forward recommendations for each of these aspects of scope. - -However, users of the decision process may want to define different scopes. -Users may define a different scope as long as the scope (1) is consistent across decisions, and (2) is credible, explicit, and accessible to all relevant decision makers. - -For example, suppliers often decline to support products beyond a declared end-of-life (EOL) date. In these cases, a supplier could reasonably consider vulnerabilities in those products to be out of scope. However, a deployer may still have active instances of EOL products in their infrastructure. It remains appropriate for a deployer to use SSVC to prioritize their response to such situations, since even if there is no remediation forthcoming from the supplier it may be possible for the deployer to mitigate or remediate the vulnerability in other ways, up to and including decommissioning the affected system(s). - -### Boundaries of the Affected System - -One distinction is whether the system of interest is software per se or a cyber-physical system. -A problem is that in every practical case, both are involved. -Software is what has vulnerabilities and is what vulnerability management is focused on remediating. -Multiple pieces of software run on any given computer system. -To consider software vulnerabilities in a useful scope, we follow prior work and propose that a vulnerability affects “the set of software instructions that executes in an environment with a coherent function and set of permissions” [@spring2015global]. -This definition is useful because it lets us keep to common usage and intuition and call the Linux kernel—at least a specific version of it—“one piece” of software. - -But decision points about safety and mission impact are not about the software in isolation; they are about the entire cyber-physical system, of which the software is a part. -The term “physical” in “cyber-physical system” should be interpreted broadly; selling stocks or manipulating press outlet content are both best understood as affecting human social institutions. -These social institutions do not have much of a corporeal instantiation, but they are physical in the sense that they are not merely software, and so are parts of cyber-physical systems. - -The hard part of delineating the boundaries of the affected system is specifying what it means for one system to be part of another system. -Just because a computer is bolted to a wall does not mean the computer is part of the wall’s purpose, which is separating physical space. -At the same time, an off-premises DNS server may be part of the site security assurance system if the on-premises security cameras rely on the DNS server to connect to the displays at the guard’s desk. -We define computer software as part of a cyber-physical system if the two systems are mutually manipulable; that is, changes in the part (the software) will (at least, often) make detectable and relevant changes to the whole (the cyber-physical system), and changes in the whole will (often) make relevant and detectable changes in the part [@spring2018generalization]. - -When reasoning about a vulnerability, we assign the vulnerability to the nearest, relevant—yet more abstract—discrete component. -This assignment is particularly important when assessing technical impact on a component. This description bears some clarification, via each of the adjectives: - - - **Nearest** is relative to the abstraction at which the vulnerability exists. - - - **Relevant** implies that the impacted component must be in the chain of abstraction moving upward from the location of the flaw. - - - **More abstract** means that the impacted component is at least one level of abstraction above the specific location of the vulnerability. For example, if the vulnerability is localized to a single line of code in a function, then the function, the module, the library, the application, the product, and the system it belongs to are all “more abstract.” - - - **Discrete** means there is an identifiable thing that can be remediated (e.g., the unit of patching). - -Products, libraries, and applications tend to be appropriate objects of focus when seeking the right level to analyze the impact of a vulnerability. -For example, when reasoning about the technical impact of a vulnerability that is localized to a function in a module in an open source library, the nearest relevant discrete abstraction is the library because the patches are made available at the library level. -Similarly, analysis of a vulnerability in closed source database software that supports an enterprise resource management (ERM) system would consider the technical impact to the database, not to the ERM system. - -### Relevant Security Policy - -Our definition of a vulnerability includes a security policy violation, but it does not clarify whose security policies are relevant [@householder2020cvd]. -For an organizational PSIRT or CSIRT, the organization's security policy is most relevant. -The answer is less clear for coordinators or ISACs. -An example scenario that brings the question into focus is phone OS jailbreak methods. -The owner of the phone may elect to jailbreak it; there is at least an implicit security policy from the owner that allows this method. -However, from the perspective of the explicit phone OS security policy embedded in the access controls and separation of privileges, the jailbreak is exploiting a vulnerability. -If a security policy is embedded in technical controls, such as OS access controls on a phone, then anything that violates that security policy is a vulnerability. - -### Reasoning Steps Forward - -This aspect of scope is about immediacy, prevalence, and causal importance. -**Immediacy** is about how soon after the decision point adverse effects should occur to be considered relevant. -**Prevalence** is about how common adverse effects should be to be considered relevant. -**Causal importance** is about how much an exploitation of the software in the cyber-physical system contributes to adverse effects to be considered relevant. -Our recommendation is to walk a pragmatic middle path on all three aspects. -Effects are not relevant if they are merely possible, too infrequent, far distant, or unchanged by the vulnerability. -But effects are relevant long before they are absolutely certain, ubiquitous, or occurring presently. -Overall, we summarize this aspect of scope as *consider credible effects based on known use cases of the software system as a part of cyber-physical systems*. diff --git a/doc/md_src_files/05_00_likely_decision_points.md b/doc/md_src_files/05_00_likely_decision_points.md deleted file mode 100644 index 47912a63..00000000 --- a/doc/md_src_files/05_00_likely_decision_points.md +++ /dev/null @@ -1,10 +0,0 @@ -# Likely Decision Points and Relevant Data - -We propose the following decision points and associated values should be a factor when making decisions about vulnerability prioritization. Each decision point is tagged with the stakeholder it is relevant to: deployers, suppliers, or both. We emphasize that these descriptions are hypotheses to be further tested and validated. We made every effort to put forward informed and useful decision frameworks with wide applicability, but the goal of this paper is more to solicit feedback than make a declaration. We welcome questions, constructive criticism, refuting evidence, or supporting evidence about any aspect of this proposal. - -One important omission from the values for each category is an “unknown” option. Instead, we recommend explicitly identifying an option that is a reasonable assumption based on prior events. Such an option requires reliable historical evidence for what tends to be the case; of course, future events may require changes to these assumptions over time. Therefore, our assumptions require evidence and are open to debate in light of new evidence. Different risk tolerance or risk discounting postures are not addressed in the current work; accommodating such tolerance or discounting explicitly is an area for future work. This flexibility fits into our overall goal of supplying a decision-making framework that is both transparent and fits the needs of different communities. Resisting an “unknown” option discourages the modeler from silently embedding these assumptions in their choices for how the decision tree flows below the selection of any “unknown” option. - -We propose satisfactory decision points for vulnerability management in the next sections, in no particular order. -Each section has a subsection with advice on gathering information about the decision point. -[SSVC using Current Information Sources](#ssvc-using-current-information-sources) will provide some suggestions about how existing sources of information about vulnerabilities can be used to collate responses to these decision points. - diff --git a/doc/md_src_files/05_01_exploitation.md b/doc/md_src_files/05_01_exploitation.md deleted file mode 100644 index 29261e31..00000000 --- a/doc/md_src_files/05_01_exploitation.md +++ /dev/null @@ -1,37 +0,0 @@ -## Exploitation -> Evidence of Active Exploitation of a Vulnerability - -The intent of this measure is the present state of exploitation of the vulnerability. The intent is not to predict future exploitation but only to acknowledge the current state of affairs. Predictive systems, such as EPSS, could be used to augment this decision or to notify stakeholders of likely changes [@jacobs2021epss]. - -Table: Exploitation Decision Values - -| Value | Definition | -| :--- |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| None | There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability. | -| PoC
(Proof of Concept) | One of the following cases is true: (1) exploit code is sold or traded on underground or restricted fora; (2) a typical public PoC in places such as Metasploit or ExploitDB; or (3) the vulnerability has a well-known method of exploitation. Some examples of condition (3) are open-source web proxies serve as the PoC code for how to exploit any vulnerability in the vein of improper validation of TLS certificates. As another example, Wireshark serves as a PoC for packet replay attacks on ethernet or WiFi networks. A publicly-known hard-coded or default password would also meet this criteria. | -| Active | Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting. | - - -### 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. -For part (3), perhaps we could construct a mapping of CWE-IDs which always represent vulnerabilities with well-known methods of exploitation. -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 the definition. -A comprehensive set of suggested CWE-IDs for this purpose is future work. - -Gathering information for [active](#exploitation) 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. -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. - -The description for [none](#exploitation) 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)). diff --git a/doc/md_src_files/05_02_technical_impact.md b/doc/md_src_files/05_02_technical_impact.md deleted file mode 100644 index f43f2a2f..00000000 --- a/doc/md_src_files/05_02_technical_impact.md +++ /dev/null @@ -1,34 +0,0 @@ -## Technical Impact -> Technical Impact of Exploiting the Vulnerability - -When evaluating [*Technical Impact*](#technical-impact), recall the scope definition in the [Scope Section](#scope). -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. -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. - -Table: Technical Impact Decision Values - -| Value | Definition | -| :--- | :------------- | -| Partial | The exploit gives the adversary *limited* control over, or information exposure about, the behavior of the software that contains the vulnerability. Or the exploit gives the adversary an importantly low stochastic opportunity for total control. In this context, “low” means that the attacker cannot reasonably make enough attempts to overcome the low chance of each attempt not working. Denial of service is a form of limited control over the behavior of the vulnerable component. | -| Total | The exploit gives the adversary *total* control over the behavior of the software, or it gives total disclosure of all information on the system that contains the vulnerability | - - -### 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. -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*. -After exploiting the vulnerability, - - can the attacker install and run arbitrary software? - - can the attacker trigger all the actions that the vulnerable component can perform? - - 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). - diff --git a/doc/md_src_files/05_03_automatable.md b/doc/md_src_files/05_03_automatable.md deleted file mode 100644 index 0b245752..00000000 --- a/doc/md_src_files/05_03_automatable.md +++ /dev/null @@ -1,38 +0,0 @@ -## Automatable - -[*Automatable*](#automatable) captures the answer to the question “Can an attacker reliably automate creating exploitation events for this vulnerability?” This metric can take the values *no* or *yes*: - - - [*no*](#automatable): Attackers cannot reliably automate steps 1-4 of the kill chain - [@hutchins2011intelligence] for this vulnerability. These - steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation. - Reasons why a step may not be reliably automatable could include the following: - 1. the vulnerable component is not searchable or enumerable on the network, - 2. weaponization may require human direction for each target, - 3. delivery may require channels that widely deployed network security configurations block, and - 4. exploitation is not reliable, due to exploit-prevention techniques enabled by default; ASLR is an example of an exploit-prevention tool. - - - [*yes*](#automatable): Attackers can reliably automate steps 1-4 of the kill chain. - If the vulnerability allows remote code execution or command injection, the expected response should be yes. - -Due to vulnerability chaining, there is some nuance as to whether reconnaissance can be automated. 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. -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. - -### 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). -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). - -Like all SSVC decision points, [*Automatable*](#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. - diff --git a/doc/md_src_files/05_04_value_density.md b/doc/md_src_files/05_04_value_density.md deleted file mode 100644 index b924bfc1..00000000 --- a/doc/md_src_files/05_04_value_density.md +++ /dev/null @@ -1,42 +0,0 @@ -## Value Density - -[*Value Density*](#value-density) is described as *diffuse* or *concentrated* based on the resources that the adversary will gain control over with a single exploitation event: - - - [*diffuse*](#value-density): The system that contains the vulnerable component has - limited resources. That is, the resources that the adversary will - gain control over with a single exploitation event are relatively - small. Examples of systems with diffuse value are email accounts, - most consumer online banking accounts, common cell phones, and most - personal computing resources owned and maintained by users. (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 - the proper operation or maintenance of a system.) - - - [*concentrated*](#value-density): The system that contains the vulnerable component - is rich in resources. Heuristically, such systems are often the - direct responsibility of “system operators” rather than users. - Examples of concentrated value are database systems, Kerberos - servers, web servers hosting login pages, and cloud service - providers. However, usefulness and uniqueness of the resources on - the vulnerable system also inform value density. For example, - encrypted mobile messaging platforms may have concentrated value, - not because each phone’s messaging history has a particularly large - amount of data, but because it is uniquely valuable to law - enforcement. - -### 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). -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. -Organizations such as Gartner produce research on the market position and product comparisons for a large variety of systems. -These generally identify how a product is deployed, used, and maintained. -An organization's own marketing materials are a less reliable indicator of how a product is used, or at least how the organization expects it to be used. - -Network telemetry can inform how many instances of a software system are connected to a network. -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. diff --git a/doc/md_src_files/05_08_human_impact.md b/doc/md_src_files/05_08_human_impact.md deleted file mode 100644 index 8944bdef..00000000 --- a/doc/md_src_files/05_08_human_impact.md +++ /dev/null @@ -1,90 +0,0 @@ -## Human Impact - > Combined Situated Safety and Mission Impact - -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 Situated Safety and Mission Impact 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. -Therefore we combine the two lesser mission impacts of degraded and MEF support crippled into a single category, while retaining the distinction between MEF Failure and Mission Failure at the extreme. -This gives us three levels of mission impact to work with. - -On the other hand, most organizations tend to have lower tolerance for variance in safety. -Even small deviations in safety are unlikely to go unnoticed or unaddressed. -We suspect that the presence of regulatory oversight for safety issues and its absence at the lower end of the mission impact scale influences this behavior. -Because of this higher sensitivity to safety concerns, we chose to retain a four-level resolution for the safety dimension. -We then combine Mission Impact with Situated Safety impact and map them onto a 4-tiered scale (Low, Medium, High, Very High). -The mapping is shown in the following table. - -Table: Combining Mission and Situated Safety Impact into Human Impact - -| Situated Safety Impact | Mission Impact | Combined Value (Human Impact) | -| -----: | :----- | :---: | -| None/Minor | Degraded/Crippled | Low | -| None/Minor | MEF Failure | Medium | -| None/Minor | Mission Failure | Very High | -| Major | Degraded/Crippled | Medium | -| Major | MEF Failure | High | -| Major | Mission Failure | Very High | -| Hazardous | Degraded/Crippled | High | -| Hazardous | MEF Failure | High | -| Hazardous | Mission Failure | Very High | -| Catastrophic | Degraded/Crippled | Very High | -| Catastrophic | MEF Failure | Very High | -| Catastrophic | Mission Failure | Very High | - - - - -### Safety and Mission Impact Decision Points for Industry Sectors - -We expect to encounter diversity in both safety and mission impacts across different organizations. However, we also anticipate a degree of commonality of impacts to arise across organizations within a given industry sector. For example, different industry sectors may have different use cases for the same software. -Therefore, vulnerability information providers—that is, vulnerability databases, 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](#guidance-on-communicating-results). - - diff --git a/doc/md_src_files/06_00_coordination_decisions.md b/doc/md_src_files/06_00_coordination_decisions.md deleted file mode 100644 index d156ead6..00000000 --- a/doc/md_src_files/06_00_coordination_decisions.md +++ /dev/null @@ -1,156 +0,0 @@ - -# Decisions During Vulnerability Coordination - -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. -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]. - -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. - -Different coordinators have different scopes and constituencies. -See [@householder2020cvd, 3.5] 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. - - - -## 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](#likely-decision-points-and-relevant-data); coordination makes use of [Utility](#utility) and [Public Safety Impact](#public-safety-impact) 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 - -Is a viable report of the details of the vulnerability already publicly available? - - - Yes - - No - -### Supplier Contacted - -Has the reporter made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method? - - - Yes - - No - -A quality contact method is a publicly posted known good email address, public portal on vendor website, etc. - -### Supplier Cardinality - -How many suppliers are responsible for the vulnerable component and its remediation or mitigation plan? - - - One - - Multiple - -### Supplier Engagement - -Is the supplier responding to the reporter's contact effort and actively participating in the coordination effort? - - - Active - - Unresponsive - -### Report Credibility - -Assessing the credibility of a report is complex, but the assessment must reach a conclusion of either: - - - Credible - - Not credible - -An analyst should start with a presumption of credibility and proceed toward disqualification. -The reason for this is that, as a coordinator, occasionally doing a bit of extra work on a bad report is preferable to rejecting legitimate reports. -This is essentially stating a preference for false positives over false negatives with respect to credibility determination. - -The following subsections provide suggestive guidance on assessing credibility. -There are no ironclad rules for this assessment, and other coordinators may find other guidance works for them. -Credibility assessment topics include indicators for and against credibility, perspective, topic, and relationship to report scope. - -#### Credibility Indicators - -The credibility of a report is assessed by a [balancing test](https://lsolum.typepad.com/legaltheory/2013/08/legal-theory-lexicon-balancing-tests.html). -The indicators for or against are not commensurate, and so they cannot be put on a scoring scale, summed, and weighed. - -A report may be treated as credible when either (1) the vendor confirms the existence of the vulnerability or (2) independent confirmation of the vulnerability by an analyst who is neither the reporter nor the vendor. -If neither of these confirmations are available, then the value of the [*Report Credibility*](#report-credibility) decision point depends on a balancing test among the following indicators. - -**Indicators *for* Credibility** include: - - The report is specific about what is affected - - The report provides sufficient detail to reproduce the vulnerability. - - The report describes an attack scenario. - - The report suggests mitigations. - - The report includes proof-of-concept exploit code or steps to reproduce. - - Screenshots and videos, if provided, support the written text of the report and do not replace it. - - The report neither exaggerates nor understates the impact. - -**Indicators *against* Credibility** include: - - The report is “spammy” or exploitative (for example, the report is an attempt to upsell the receiver on some product or service). - - The report is vague or ambiguous about which vendors, products, or versions are affected (for example, the report claims that all “cell phones” or “wifi” or “routers” are affected). - - The report is vague or ambiguous about the preconditions necessary to exploit the vulnerability. - - The report is vague or ambiguous about the impact if exploited. - - The report exaggerates the impact if exploited. - - The report makes extraordinary claims without correspondingly extraordinary evidence (for example, the report claims that exploitation could result in catastrophic damage to some critical system without a clear causal connection between the facts presented and the impacts claimed). - - The report is unclear about what the attacker gains by exploiting the vulnerability. What do they get that they didn't already have? For example, an attacker with system privileges can already do lots of bad things, so a report that assumes system privileges as a precondition to exploitation needs to explain what else this gives the attacker. - - The report depends on preconditions that are extremely rare in practice, and lacks adequate evidence for why those preconditions might be expected to occur (for example, the vulnerability is only exposed in certain non-default configurations—unless there is evidence that a community of practice has established a norm of such a non-default setup). - - The report claims dire impact for a trivially found vulnerability. It is not impossible for this to occur, but most products and services that have been around for a while have already had their low-hanging fruit major vulnerabilities picked. One notable exception would be if the reporter applied a completely new method for finding vulnerabilities to discover the subject of the report. - - The report is rambling and is more about a narrative than describing the vulnerability. One description is that the report reads like a food recipe with the obligatory search engine optimization preamble. - - The reporter is known to have submitted low-quality reports in the past. - - The report conspicuously misuses technical terminology. This is evidence that the reporter may not understand what they are talking about. - - The analyst's professional colleagues consider the report to be not credible. - - The report consists of mostly raw tool output. Fuzz testing outputs are not vulnerability reports. - - The report lacks sufficient detail for someone to reproduce the vulnerability. - - The report is just a link to a video or set of images, or lacks written detail while claiming “it's all in the video”. Imagery should support a written description, not replace it. - - The report describes a bug with no discernible security impact. - - The report fails to describe an attack scenario, and none is obvious. - -We considered adding poor grammar or spelling as an indicator of non-credibility. -On further reflection, we do not recommend that poor grammar or spelling be used as an indicator of low report quality, as many reporters may not be native to the coordinator's language. -Poor grammar alone is not sufficient to dismiss a report as not credible. -Even when poor grammar is accompanied by other indicators of non-credibility, those other indicators are sufficient to make the determination. - -#### Credibility of what to whom - -SSVC is interested in the coordinating analyst's assessment of the credibility of a report. -This is separate from the fact that a reporter probably reports something because they believe the report is credible. - -The analyst should assess the credibility of the report of the vulnerability, not the claims of the impact of the vulnerability. -A report may be credible in terms of the fact of the vulnerability's existence even if the stated impacts are inaccurate. -However, the more extreme the stated impacts are, the more skepticism is necessary. -For this reason, “exaggerating the impact if exploited” is an indicator *against* credibility. -Furthermore, a report may be factual but not identify any security implications; such reports are bug reports, not vulnerability reports, and are considered out of scope. - -A coordinator also has a scope defined by their specific constituency and mission. -A report can be entirely credible yet remain out of scope for your coordination practice. -Decide what to do about out of scope reports separately, before the vulnerability coordination triage decision begins. -If a report arrives and would be out of scope even if true, there will be no need to proceed with judging its credibility. - - - -## Coordination Triage Decision Process - -The decision tree for reaching a [Decision](#coordination-triage-decisions) 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). - -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) diff --git a/doc/md_src_files/06_04_publication_decision.md b/doc/md_src_files/06_04_publication_decision.md deleted file mode 100644 index 160e9382..00000000 --- a/doc/md_src_files/06_04_publication_decision.md +++ /dev/null @@ -1,50 +0,0 @@ -## 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. - -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. -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. -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. -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. - -In addition to the two decision points defined in this section, the publication decision uses the [*Exploitation*](#exploitation) decision point. - -### Public Value Added - -This decision point asks how much value a publication from the coordinator would benefit the broader community. -The value is based on the state of existing public information about the vulnerablity. - - - *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. - -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. - -### Supplier Involvement - -This decision point accounts for the state of the supplier's work on addressing the vulnerability. - - - *Fix Ready*—the supplier has provided a patch or fix. - - *Cooperative*—the supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time. - - *Uncooperative/Unresponsive*—the supplier has not responded, declined to generate a remediation, or no longer exists. diff --git a/doc/md_src_files/07_01_supplier_tree.md b/doc/md_src_files/07_01_supplier_tree.md deleted file mode 100644 index 8d38d2bb..00000000 --- a/doc/md_src_files/07_01_supplier_tree.md +++ /dev/null @@ -1,18 +0,0 @@ -## Supplier Tree - -The example supplier tree [PDF](../graphics/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: - - - Defer = gray with green outline - - Scheduled = yellow - - Out-of-Cycle = orange - - Immediate = red with black outline - -![Suggested Supplier Tree](../graphics/ssvc_2_supplier.pdf){ width=100% } - - - - diff --git a/doc/md_src_files/07_02_deployer_tree.md b/doc/md_src_files/07_02_deployer_tree.md deleted file mode 100644 index a2c75d46..00000000 --- a/doc/md_src_files/07_02_deployer_tree.md +++ /dev/null @@ -1,13 +0,0 @@ -## Deployer Tree - -The example deployer tree [PDF](../graphics/ssvc_2_deployer_SeEUMss.pdf) is depicted below. - - -![Suggested Deployer Tree](../graphics/ssvc_2_deployer_SeEUMss.pdf){ width=100% } - - diff --git a/doc/md_src_files/07_03_coordinator_trees.md b/doc/md_src_files/07_03_coordinator_trees.md deleted file mode 100644 index c99fc58b..00000000 --- a/doc/md_src_files/07_03_coordinator_trees.md +++ /dev/null @@ -1,32 +0,0 @@ -## Coordinator Trees - -As described in [Decisions During Vulnerability Coordination](#decisions-during-vulnerability-coordination), a coordination stakeholder usually makes separate triage and publication decisions. Each have trees presented below. - -### Triage Decision Tree - - -![Suggested Coordinator Triage Tree](../graphics/ssvc_2_coord-triage.pdf){ width=100% } - - - -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). - -### Publication Decision Tree - -Suggested decision values for this decision are available in [CSV](../../data/csvs/ssvc_2_coord-publish.csv) and [PDF](../graphics/ssvc_2_coord-publish.pdf) formats. - - -![Suggested Coordinator Publication Tree](../graphics/ssvc_2_coord-publish.pdf){ width=100% } - - - - diff --git a/doc/md_src_files/07_05_evidence_gathering.md b/doc/md_src_files/07_05_evidence_gathering.md deleted file mode 100644 index 8342aed0..00000000 --- a/doc/md_src_files/07_05_evidence_gathering.md +++ /dev/null @@ -1,23 +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. - -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. 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. 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. - -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. -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). -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. -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). -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/doc/md_src_files/11_worked_example.md b/doc/md_src_files/11_worked_example.md deleted file mode 100644 index 3e5c5b53..00000000 --- a/doc/md_src_files/11_worked_example.md +++ /dev/null @@ -1,37 +0,0 @@ - -# Worked Example - -As an example, we will evaluate CVE-2018-14781 step by step from the deployer point of view. The scenario here is that used for the pilot study. This example uses the SSVC version 1 deployer decision tree. - -The analyst’s first question is related to exploitation. Technically, one could answer the questions in any order; however, exploitation is a good starting point because given an adequately defined search procedure, one can always answer whether it finds an available exploit or proof of concept. The scenario description for the pilot study reads as follows: - - - **State of exploitation**: Metasploit and ExploitDB do not return results for this vulnerability. The NVD does not report any active exploitation of this vulnerability. - -This information rules out “active” given the (perhaps limited) search procedure. While the search did not produce a precise PoC, based on the description of the vulnerability, it is a fairly standard traffic capture and replay attack that, given access to the transmission medium, should be straightforward to conduct with Wireshark. Therefore, we select the “PoC” branch and then ask about exposure. This considers the (fictional) deployer scenario blurb and the notional deployment of the affected system, as follows. - - - **Scenario blurb**: We are a hospital that uses Medtronic devices frequently because of their quality and popularity in the market. We give these devices out to clients who need to monitor and track their insulin intake. If clients need to access data on their device, they can physically connect it to their computer or connect via Bluetooth to an app on their phone for monitoring capabilities. Occasionally, clients who use this device will have a doctor’s appointment in which the doctors have machines that can access the device as well to monitor or change settings. It is unknown how secure the doctor’s computer that interfaces directly with this insulin pump is. If the doctor’s computer is compromised, it potentially means that every device that connects to it is compromised as well. If an update to the insulin pump is required, a client can do this on their own through their computer or app or through a doctor while they are on-site at the hospital. - - - **Deployment of affected system**: 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. -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. -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). -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). -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. - -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 is complex, with many MEFs. However, even from this abstract, it seems clear that “do no harm” is at risk due to this vulnerability. A mission essential function to that mission is each of the various medical devices works as expected, or at least if a device fails, it cannot actively be used to inflict harm. Unsolicited insulin delivery would mean that MEF “fails for a period of time longer than acceptable,” matching the 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. - -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. -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: - - - **Use of the cyber-physical system**: Insulin pumps are used to regulate blood glucose levels in diabetics. Diabetes is extremely common in the US. Misregulation of glucose can cause a variety of problems. Minor misregulation causes confusion or difficulty concentrating. Long-term minor mismanagement causes weigh management issues and blindness. Severe acute mismanagement can lead unconsciousness in a matter of minutes and death in a matter of hours. 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 “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). -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). -The pilot information is inadequate in this regard, which is the likely source of disagreement about [*Safety Impact*](#safety-impact) 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). -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/doc/md_src_files/19_reference_definitions.md b/doc/md_src_files/19_reference_definitions.md deleted file mode 100644 index 8b137891..00000000 --- a/doc/md_src_files/19_reference_definitions.md +++ /dev/null @@ -1 +0,0 @@ - diff --git a/doc/md_src_files/sources_ssvc.bib b/doc/md_src_files/sources_ssvc.bib index 68c22bca..e42cce40 100644 --- a/doc/md_src_files/sources_ssvc.bib +++ b/doc/md_src_files/sources_ssvc.bib @@ -55,10 +55,10 @@ @article{falotico2015fleiss @article{spring2018litrev, - title = {Review of Human Decision-making during Incident Analysis}, title = {Review of Human Decision-Making during Computer Security Incident Analysis}, year = {2021}, publisher = {ACM}, + author={Spring, Jonathan M}, address = {New York, NY, USA}, volume = {2}, number = {2}, @@ -76,7 +76,7 @@ @article{spring2018generalization title = {Building General Knowledge of Mechanisms in Information Security}, author = {Spring, Jonathan M and Phyllis Illari}, date = {2018-09-17}, - journal = {Philosophy \& Technology}, + year={2018},journal = {Philosophy \& Technology}, volume = {32}, number = {}, publisher = {Springer}, @@ -114,6 +114,7 @@ @article{pendleton2016survey volume = {49}, number = {4}, date = {2016-12}, + year= {2016}, pages = {62:1--62:35}, articleno = {62}, publisher = {ACM}, @@ -196,6 +197,7 @@ @inproceedings{allodi2018effect author={Allodi, Luca and Cremonini, Marco and Massacci, Fabio and Shim, Woohyun}, booktitle={Workshop on Economics of Information Security}, date={2018-06}, + year={2018}, address = {Innsbruck, Austria} } @@ -203,6 +205,7 @@ @inproceedings{spring2017why title = {Practicing a Science of Security: A philosophy of science perspective}, author = {Spring, Jonathan M and Tyler Moore and David Pym}, date = {2017-10-02}, + year = {2017}, booktitle = {New Security Paradigms Workshop}, address = {Santa Cruz, CA, USA}, url = {https://tylermoore.utulsa.edu/nspw17.pdf} @@ -214,7 +217,7 @@ @inproceedings{spring2015global booktitle={APWG Symposium on Electronic Crime Research (eCrime)}, pages={}, date={2015-05-27}, - address={Barcelona}, + year={2015},address={Barcelona}, organization={IEEE} } @@ -243,7 +246,8 @@ @inproceedings{householder2020historical booktitle= {Workshop on Cyber Security Experimentation and Test}, publisher = {USENIX}, address = {Virtual conference}, - date={2020-08-10} + date={2020-08-10}, + year={2020} } @inproceedings{metcalf2015blocklist, @@ -252,7 +256,7 @@ @inproceedings{metcalf2015blocklist booktitle={Workshop on Information Sharing and Collaborative Security}, pages={13--22}, date={2015-10-12}, - publisher = {ACM}, + year={2015},publisher = {ACM}, address={Denver} } @@ -262,7 +266,7 @@ @inproceedings{kuhrer2014paint booktitle={Recent Advances in Intrusion Detection}, pages={1--21}, date={2014-09-17}, - address = {Gothenburg, Sweden}, + year={2014},address = {Gothenburg, Sweden}, organization={Springer}, series = {LNCS}, number = {8688} @@ -277,6 +281,7 @@ @techreport{csirtservices_v2 title={Computer Security Incident Response Team {(CSIRT)} Services Framework}, author={Vilius Benetis and Olivier Caleff and Cristine Hoepers and Angela Horneman and Allen Householder and Klaus-Peter Kossakowski and Art Manion and Amanda Mullens and Samuel Perl and Daniel Roethlisberger and Sigitas Rokas and Mary Rossell and Robin M. Ruefle and D{'e}sir{'e}e Sacher and Krassimir T. Tzvetanov and Mark Zajicek}, date={2019-07-01}, + year=2019, number = {ver. 2}, address = {Cary, NC, USA}, institution={FIRST} @@ -285,8 +290,9 @@ @techreport{csirtservices_v2 @techreport{pcidss_v3, title={Payment Card Industry (PCI) Data Security Standard: Approved Scanning Vendors}, date={2017-02}, - number={ver 3.0}, + year={2017},number={ver 3.0}, author={{PCI Security Standards Council}}, + institution={{PCI Security Standards Council}}, address={Wakefield, MA, USA}, url={https://www.pcisecuritystandards.org/documents/ASV_Program_Guide_v3.0.pdf} } @@ -295,7 +301,7 @@ @techreport{manion2009vrda title={Effectiveness of the Vulnerability Response Decision Assistance {(VRDA)} Framework}, author={Art Manion and Kazuya Togashi and Joseph B. Kadane and Fumihiko Kousaka and Shawn McCaffrey and Christopher King and Masanori Yamaguchi and Robert Weiland}, date={2009-08}, - number={}, + year={2009},number={}, institution={Software Engineering Institute, Carnegie Mellon University}, address={Pittsburgh, PA}, url={https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=50301}, @@ -315,6 +321,7 @@ @techreport{DO-178C title = {Software Considerations in Airborne Systems and Equipment Certification}, author = {{RTCA, Inc.}}, date = {2012-01}, + year={2012}, institution = {EUROCAE WG-12}, number = {DO-178C}, address = {Washington, DC} @@ -345,7 +352,7 @@ @techreport{guido2011exploit author={Guido, Dan}, institution={iSEC Partners}, date = {2011-07-25}, - url={http://www.trailofbits.com/resources/exploit_intelligence_project_2_slides.pdf} + year={2011},url={http://www.trailofbits.com/resources/exploit_intelligence_project_2_slides.pdf} } @techreport{spring2019ml, @@ -388,7 +395,7 @@ @online{tucker2018octave author = {Brett Tucker}, title = {OCTAVE\textregistered ~FORTE and FAIR Connect Cyber Risk Practitioners with the Boardroom}, date = {2018-06}, - urldate = {2020-01-20}, + year={2018},urldate = {2020-01-20}, url = {https://insights.sei.cmu.edu/insider-threat/2018/06/octave-forte-and-fair-connect-cyber-risk-practitioners-with-the-boardroom.html} } @@ -396,7 +403,7 @@ @online{akbar2020ssvc author = {Muhammad Akbar}, title = {A Critical First Look at Stakeholder Specific Vulnerability Categorization (SSVC)}, date = {2020-03-06}, - urldate = {2020-06-20}, + year={2020},urldate = {2020-06-20}, url = {https://blog.secursive.com/posts/critical-look-stakeholder-specific-vulnerability-categorization-ssvc/} } @@ -443,7 +450,7 @@ @techreport{mitre2019medical title={Rubric for Applying CVSS to Medical Devices}, author={Melissa P Chase and Steven M Cristey Coley}, date={2019-01}, - number = {18-2208}, + year={2019},number = {18-2208}, address = {McLean, VA, USA}, institution={MITRE Corporation}, url = {https://www.mitre.org/publications/technical-papers/rubric-for-applying-cvss-to-medical-devices} @@ -454,7 +461,8 @@ @techreport{spring2018cvss author={Jonathan M Spring and Eric Hatleback and Allen D Householder and Art Manion and Deana Shick}, institution={Software Engineering Institute, Carnegie Mellon University}, address={Pittsburgh, PA}, - date={2018-12} + date={2018-12}, + year={2018} } @article{vilches2018towards, @@ -468,7 +476,7 @@ @article{figueroa2020survey author = {Figueroa-Lorenzo, Santiago and A\~{n}orga, Javier and Arrizabalaga, Saioa}, title = {A Survey of {IIoT} Protocols: A Measure of Vulnerability Risk Analysis Based on CVSS}, date = {2020-04}, - issue_date = {April 2020}, + year={2020},issue_date = {April 2020}, address = {New York, NY, USA}, volume = {53}, number = {2}, @@ -487,7 +495,7 @@ @techreport{nist800-115 author = {Karen Scarfone and Murugiah Souppaya and Amanda Cody and Angela Orebaugh}, number={SP 800-115}, date={2008-09}, - address = {Gaithersburg, MD}, + year={2008},address = {Gaithersburg, MD}, institution={US Dept of Commerce, National Institute of Standards and Technology} } @@ -496,7 +504,7 @@ @techreport{nist800-40r3 author = {Souppaya, Muragiah and Karen Scarfone}, number={SP 800-40r3}, date={2013-07}, - address = {Gaithersburg, MD}, + year={2013},address = {Gaithersburg, MD}, institution={US Dept of Commerce, National Institute of Standards and Technology} } @@ -516,6 +524,7 @@ @techreport{faa2000safety author = {{FAA}}, institution = {US Dept. of Transportation, Federal Aviation Administration}, date = {2000-12-30}, + year = {2000}, url = {https://www.faa.gov/regulations_policies/handbooks_manuals/aviation/risk_management/ss_handbook/}, address = {Washington, DC} } @@ -525,6 +534,8 @@ @techreport{FCD2_2017 shortauthor = {{FEMA}}, editor={Robert J. Fenton}, date={2017-06-13}, + year={2017}, + author={Federal Emergency Management Agency}, institution={US Department of Homeland Security, Federal Emergency Management Agency}, url={https://www.fema.gov/media-library-data/1499702987348-c8eb5e5746bfc5a7a3cb954039df7fc2/FCD-2June132017.pdf} } @@ -533,6 +544,8 @@ @techreport{dod3026_26_2018 title={DoD Directive 3020.26 DoD Continuity Policy}, shortauthor={{DOD}}, date={2018-02-18}, + year={2018}, + author={DOD}, institution={US Department of Defense}, url={https://github.com/CERTCC/SSVC/pull/281/commits/791dcabd716c2e681215493b26cba79f3863887b} } @@ -552,7 +565,7 @@ @online{bod15-01 title = {Critical Vulnerability Mitigation}, author = {{Cybersecurity and Infrastructure Security Agency}}, date = {2015-05-21}, - urldate = {2020-08-21}, + year={2015},urldate = {2020-08-21}, note = {Superseded by BOD19-02} } @techreport{dodi_8531_2020, @@ -560,7 +573,7 @@ @techreport{dodi_8531_2020 title = {DoD Instruction 8531.01 DoD Vulnerability Management}, author = {{Office of the DoD Chief Information Officer}}, date = {2020-09-15}, - institution = {Department of Defense}, + year={2020},institution = {Department of Defense}, address = {Washington, DC}, } %%%% End US government publications diff --git a/doc/obsolete/compile-html-citeproc.sh b/doc/obsolete/compile-html-citeproc.sh deleted file mode 100755 index 8889577b..00000000 --- a/doc/obsolete/compile-html-citeproc.sh +++ /dev/null @@ -1,24 +0,0 @@ -#!/bin/sh -src="./md_src_files" - -pandoc --self-contained \ - --from=markdown_github+citations+table_captions+implicit_figures+link_attributes \ - --to=html \ - --citeproc \ - --bibliography="$src/sources_ssvc.bib" \ - -M title="Prioritizing vulnerability response: A stakeholder-specific vulnerability categorization (DRAFT version 2.0)" \ - -T "SSVC" \ - -M author="Jonathan M. Spring; Eric Hatleback; Allen D. Householder; Art Manion; Madison Oliver; Vijay Sarvapalli; Deana Shick; Laurie Tyzenhaus" \ - -M date="Compiled `date -u`" \ - -o ssvc_v2-0.html \ - $src/*md - -# --from should use gfm, but gfm+citations is not supported -# so this method should perhaps be considered slightly unstable. -# This citation syntax won't render on github -# but the @ citation syntax shouldn't interfere with @ mentions -# GFM only allows @ mentions in issues and pull requests -# https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown -# documentation for citation processing: -# https://pandoc.org/MANUAL.html#citations - diff --git a/doc/obsolete/compile-pdf.sh b/doc/obsolete/compile-pdf.sh deleted file mode 100755 index 6828faba..00000000 --- a/doc/obsolete/compile-pdf.sh +++ /dev/null @@ -1,50 +0,0 @@ -#!/bin/sh -src="./md_src_files" - -# HTML can handle emojis and not LaTeX commands, so the markdown files have emoji -# However, it is really hard to embed emoji into PDFs in a platform-independent way -# Apple Emoji font and Noto Emoji font are the two options, basically, and as of Apr 2022 -# most devices seem to have one or the other. -# In general, LaTeX is bad at emojis, but the twemojis package might make it OK. -# However, twemojis is not a default package yet, so avoiding that for now. -# So the best available option is to temporarily replace them with LaTeX commands -# Pandoc will read from stdin if no input files are provided, so sed works inline. - -# versioning -# need a better way of automatically updating version numbers -major="2" -minor="0" -# these have the common meanings from semantic versioning -# major should be incremented with content changes that introduce incompatibilities -# minor should be incremented for meaningful changes that do not break compatibility -fix="5" -# fix version needs to be incremented with every commit - -#versioning across different content is a bit complicated. -# The PDF major.minor should match any schema, tree, or other supporting document version -# This means if the major.minor version changes, the schemas need a numbering change -# The fix version for the schema and the PDF document may mismatch - -sed -f emoji-replacements.sed $src/*md | \ -pandoc --standalone \ - --from=markdown_github+citations+yaml_metadata_block+tex_math_dollars \ - --to=pdf \ - --citeproc \ - --pdf-engine=xelatex \ - --bibliography="$src/sources_ssvc.bib" \ - --table-of-contents \ - -M title="Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (SSVC version $major.$minor.$fix)" \ - -T "SSVC" \ - -M date="Compiled `date -u`" \ - --metadata-file=pdf-styling.yaml \ - -o "ssvc_$major-$minor-$fix.pdf" \ - -# --from should use gfm, but gfm+citations is not supported -# so this method should perhaps be considered slightly unstable. -# This citation syntax won't render on github -# but the @ citation syntax shouldn't interfere with @ mentions -# GFM only allows @ mentions in issues and pull requests -# https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown -# documentation for citation processing: -# https://pandoc.org/MANUAL.html#citations - diff --git a/doc/obsolete/compile-v1.sh b/doc/obsolete/compile-v1.sh deleted file mode 100755 index 80f16e2d..00000000 --- a/doc/obsolete/compile-v1.sh +++ /dev/null @@ -1,22 +0,0 @@ -#!/bin/sh -pandoc --standalone --from=markdown_github+citations --to=html \ - --filter pandoc-citeproc \ - --bibliography="version_1/sources_ssvc.bib" \ - -M title="Prioritizing vulnerability response: A stakeholder-specific vulnerability categorization (version 1.1)" \ - -T "SSVC" \ - -M author="Jonathan M. Spring; Eric Hatleback; Allen Householder; Art Manion; Deana Shick" \ - -M date="Published 2020-06-25; compiled `date -u`" \ - -M reference-section-title="References" \ - -M link-citations="true" \ - -o ssvc_v1-1.html \ - version_1/*md - -# --from should use gfm, but gfm+citations is not supported -# so this method should perhaps be considered slightly unstable. -# This citation syntax won't render on github -# but the @ citation syntax shouldn't interfere with @ mentions -# GFM only allows @ mentions in issues and pull requests -# https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown -# documentation for citation processing: -# https://pandoc.org/MANUAL.html#citations - diff --git a/doc/md_src_files/16_acknowledgements.md b/docs/about/acknowledgements.md similarity index 99% rename from doc/md_src_files/16_acknowledgements.md rename to docs/about/acknowledgements.md index ce1fd6a0..b2176f46 100644 --- a/doc/md_src_files/16_acknowledgements.md +++ b/docs/about/acknowledgements.md @@ -24,5 +24,3 @@ Various staff members and analysts at CERT/CC, CISA, McAfee, and VMWare; FIRST CVSS SIG and EPSS SIG members; and others who wish to remain anonymous. - - diff --git a/doc/md_src_files/09_changelog.md b/docs/about/changelog.md similarity index 100% rename from doc/md_src_files/09_changelog.md rename to docs/about/changelog.md diff --git a/doc/md_src_files/17_contact_us.md b/docs/about/contact_us.md similarity index 77% rename from doc/md_src_files/17_contact_us.md rename to docs/about/contact_us.md index f6fe8e4b..63fc35de 100644 --- a/doc/md_src_files/17_contact_us.md +++ b/docs/about/contact_us.md @@ -6,4 +6,4 @@ Software Engineering Institute **Phone**: 412.268.5800 | 888.201.4479 **Web**: [www.sei.cmu.edu](http://www.sei.cmu.edu) -**Email**: info@sei.cmu.edu +**Email**: [info@sei.cmu.edu](mailto:info@sei.cmu.edu) diff --git a/docs/about/contributing.md b/docs/about/contributing.md new file mode 100644 index 00000000..3f0c5a8a --- /dev/null +++ b/docs/about/contributing.md @@ -0,0 +1 @@ +{% include-markdown "../../CONTRIBUTING.md" %} \ No newline at end of file diff --git a/doc/md_src_files/18_copyright.md b/docs/about/copyright.md similarity index 100% rename from doc/md_src_files/18_copyright.md rename to docs/about/copyright.md diff --git a/doc/md_src_files/15_conclusion.md b/docs/about/index.md similarity index 84% rename from doc/md_src_files/15_conclusion.md rename to docs/about/index.md index 824b01d8..d41c12ee 100644 --- a/doc/md_src_files/15_conclusion.md +++ b/docs/about/index.md @@ -1,7 +1,4 @@ - - - -# Conclusion +# About SSVC SSVC version 2 presents a method for suppliers, deployers, and coordinators to use to prioritize their effort to mitigate vulnerabilities. We have built on SSVC version 1 through public presentation and feedback, private consultation, and continued analyst testing. @@ -10,3 +7,10 @@ We invite participation and further refinement of the prioritization mechanism f We endeavored to be transparent about our process and provide justification for design decisions. We invite questions, comments, and further community refinement in moving forward with a transparent and justified vulnerability prioritization methodology that is inclusive for the various stakeholders and industries that develop and use information and computer technology. + + +- [Acknowledgements](acknowledgements.md) +- [Change Log](changelog.md) +- [Contributing](contributing.md) +- [Copyright](copyright.md) +- [Contact Us](contact_us.md) \ No newline at end of file diff --git a/docs/assets/cert_seal.svg b/docs/assets/cert_seal.svg new file mode 100644 index 00000000..980c324c --- /dev/null +++ b/docs/assets/cert_seal.svg @@ -0,0 +1 @@ +cert_seal \ No newline at end of file diff --git a/doc/md_src_files/07_06_asset_management.md b/docs/howto/asset_management.md similarity index 64% rename from doc/md_src_files/07_06_asset_management.md rename to docs/howto/asset_management.md index 467dfd79..c156b07e 100644 --- a/doc/md_src_files/07_06_asset_management.md +++ b/docs/howto/asset_management.md @@ -1,21 +1,27 @@ -## Relationship to asset management +# SSVC and Asset Management Vulnerability management is a part of asset management. SSVC can benefit from asset management practices and systems, particularly in regard to automating data collection and answers for some decision points. SSVC depends on asset management to some extent, particularly for context on the cost and risk associated with changing or updating the asset. -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. -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. +!!! 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. + 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. 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. There are at least three aspects of asset management that may be important but are out of scope for SSVC. -First and most obvious is the transaction cost of conducting the mitigation or remediation. + +1. **Mitigation Cost** First and most obvious is the transaction cost of conducting the mitigation or remediation. System administrators are paid to develop or apply any remediations or mitigations, and there may be other transactional costs such as downtime for updates. -Second is the risk of the remediation or mitigation introducing a new error or vulnerability. -Regression testing is part of managing this type of risk. Finally, there may be an operational cost of applying a remediation or mitigation, representing an ongoing change of functionality or increased overhead. + +2. **Mitigation Risk** Second is the risk of the remediation or mitigation introducing a new error or vulnerability. +Regression testing is part of managing this type of risk. + +3. **Operational Cost** Finally, there may be an operational cost of applying a remediation or mitigation, representing an ongoing change of functionality or increased overhead. A decision maker could order work within one SSVC priority class (scheduled, out-of-cycle, etc.) based on these asset management considerations, for example. Once the organization remediates or mitigates all the high-priority vulnerabilities, they can then focus on the medium-level vulnerabilities with the same effort spent on the high-priority ones. diff --git a/doc/md_src_files/08_communicating_results.md b/docs/howto/communicating_results.md similarity index 100% rename from doc/md_src_files/08_communicating_results.md rename to docs/howto/communicating_results.md diff --git a/docs/howto/coordination_decisions.md b/docs/howto/coordination_decisions.md new file mode 100644 index 00000000..238f5a07 --- /dev/null +++ b/docs/howto/coordination_decisions.md @@ -0,0 +1,56 @@ + +# Decisions During Vulnerability Coordination + +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. +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]. + +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. + +Different coordinators have different scopes and constituencies. +See [@householder2020cvd, 3.5] 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. + + + +## 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](#likely-decision-points-and-relevant-data); coordination makes use of [Utility](#utility) and [Public Safety Impact](#public-safety-impact) 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. + +{== TODO link to specific decision points ==} + +## Coordination Triage Decision Process + +The decision tree for reaching a [Decision](#coordination-triage-decisions) 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). + +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) + +{== TODO merge with [Coordinator Trees](coordinator_trees.md)? ==} \ No newline at end of file diff --git a/docs/howto/coordinator_publish_tree.md b/docs/howto/coordinator_publish_tree.md new file mode 100644 index 00000000..dc1d167b --- /dev/null +++ b/docs/howto/coordinator_publish_tree.md @@ -0,0 +1,124 @@ +# 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 new file mode 100644 index 00000000..df828084 --- /dev/null +++ b/docs/howto/coordinator_trees.md @@ -0,0 +1,17 @@ +# Coordinator Trees + +As described in [Decisions During Vulnerability Coordination](#decisions-during-vulnerability-coordination), a coordination stakeholder usually makes separate triage and publication decisions. Each have trees presented below. + +## 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 new file mode 100644 index 00000000..23e8a10b --- /dev/null +++ b/docs/howto/deployer_tree.md @@ -0,0 +1,13 @@ +# Deployer Tree + +The example deployer tree [PDF](../pdf/ssvc_2_deployer_SeEUMss.pdf) is depicted below. + + + + +## Table of Values + +{{ read_csv('data/csvs/deployer-options.csv') }} \ No newline at end of file diff --git a/docs/howto/evidence_gathering.md b/docs/howto/evidence_gathering.md new file mode 100644 index 00000000..fd4a67a6 --- /dev/null +++ b/docs/howto/evidence_gathering.md @@ -0,0 +1,84 @@ +# 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 new file mode 100644 index 00000000..0686af5e --- /dev/null +++ b/docs/howto/index.md @@ -0,0 +1,25 @@ +# Using SSVC + +!!! tip inline end "Prerequisites" + + The [Using SSVC](/docs/howto/index.md) section assumes that you have + + - An interest in using SSVC in a vulnerability management process + - Basic familiarity with SSVC + + If you are unfamiliar with SSVC, we suggest you start with the + [Understanding SSVC](../topics/background/index.md) section, which provides necessary background detail. + For technical reference, see [Reference](../reference/index.md). + +!!! note "TODO: What should go here?" + + Advice for practitioners looking to integrate SSVC into their vulnerability management process. + + - example trees showing how decision points are used to model decisions + - how to model new decisions + - how to create more decision points + - how to modify or adapt existing decision points + - how to analyze trees for quality/parsimony + - how to integrate SSVC into existing processes + - how to integrate data sources into SSVC decision points + diff --git a/doc/md_src_files/07_00_prioritization.md b/docs/howto/prioritization.md similarity index 100% rename from doc/md_src_files/07_00_prioritization.md rename to docs/howto/prioritization.md diff --git a/docs/howto/publication_decision.md b/docs/howto/publication_decision.md new file mode 100644 index 00000000..64400f54 --- /dev/null +++ b/docs/howto/publication_decision.md @@ -0,0 +1,36 @@ +# 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. + +!!! 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. + 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. + + 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. + +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. + +In addition to the two decision points defined in this section, the publication decision uses the [*Exploitation*](#exploitation) 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 diff --git a/docs/howto/supplier_tree.md b/docs/howto/supplier_tree.md new file mode 100644 index 00000000..deb6c3b2 --- /dev/null +++ b/docs/howto/supplier_tree.md @@ -0,0 +1,17 @@ +# Supplier Tree + +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: + + - Defer = gray with green outline + - Scheduled = yellow + - Out-of-Cycle = orange + - Immediate = red with black outline + + + + +## Table of Values + +{{ read_csv('data/csvs/supplier-options.csv') }} \ No newline at end of file diff --git a/doc/md_src_files/07_04_tree_customization.md b/docs/howto/tree_customization.md similarity index 100% rename from doc/md_src_files/07_04_tree_customization.md rename to docs/howto/tree_customization.md diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 00000000..7d30e1ee --- /dev/null +++ b/docs/index.md @@ -0,0 +1,7 @@ +# Stakeholder-Specific Vulnerability Categorization + +!!! warning "Work in Progress" + + This website is a work in progress. + While it is intended to eventually be the official documentation for SSVC, it is not yet complete. + For the latest version of SSVC documentation, see the [GitHub repository](https://github.com/CERTCC/SSVC). \ No newline at end of file diff --git a/docs/javascripts/mathjax.js b/docs/javascripts/mathjax.js new file mode 100644 index 00000000..06dbf38b --- /dev/null +++ b/docs/javascripts/mathjax.js @@ -0,0 +1,16 @@ +window.MathJax = { + tex: { + inlineMath: [["\\(", "\\)"]], + displayMath: [["\\[", "\\]"]], + processEscapes: true, + processEnvironments: true + }, + options: { + ignoreHtmlClass: ".*|", + processHtmlClass: "arithmatex" + } +}; + +document$.subscribe(() => { + MathJax.typesetPromise() +}) diff --git a/docs/javascripts/tablesort.js b/docs/javascripts/tablesort.js new file mode 100644 index 00000000..6a5afcf2 --- /dev/null +++ b/docs/javascripts/tablesort.js @@ -0,0 +1,6 @@ +document$.subscribe(function() { + var tables = document.querySelectorAll("article table:not([class])") + tables.forEach(function(table) { + new Tablesort(table) + }) +}) diff --git a/doc/graphics/ssvc_2_coord-publish.pdf b/docs/pdf/ssvc_2_coord-publish.pdf similarity index 100% rename from doc/graphics/ssvc_2_coord-publish.pdf rename to docs/pdf/ssvc_2_coord-publish.pdf diff --git a/doc/graphics/ssvc_2_coord-triage.pdf b/docs/pdf/ssvc_2_coord-triage.pdf similarity index 100% rename from doc/graphics/ssvc_2_coord-triage.pdf rename to docs/pdf/ssvc_2_coord-triage.pdf diff --git a/doc/graphics/ssvc_2_deployer_SeEUMss.pdf b/docs/pdf/ssvc_2_deployer_SeEUMss.pdf similarity index 100% rename from doc/graphics/ssvc_2_deployer_SeEUMss.pdf rename to docs/pdf/ssvc_2_deployer_SeEUMss.pdf diff --git a/doc/graphics/ssvc_2_supplier.pdf b/docs/pdf/ssvc_2_supplier.pdf similarity index 100% rename from doc/graphics/ssvc_2_supplier.pdf rename to docs/pdf/ssvc_2_supplier.pdf diff --git a/docs/reference/decision_points/automatable.md b/docs/reference/decision_points/automatable.md new file mode 100644 index 00000000..334b7f6d --- /dev/null +++ b/docs/reference/decision_points/automatable.md @@ -0,0 +1,80 @@ +!!! note "Automatable" + + === "Text" + Can an attacker reliably automate creating exploitation events for this vulnerability? + + | Value | Definition | + | :--- | :---------- | + | no | Attackers cannot reliably automate steps 1-4 of the kill chain [@hutchins2011intelligence] for this vulnerability. | + | yes | Attackers can reliably automate steps 1-4 of the kill chain. | + + === "JSON" + This is a made up example and does not reflect the correct format. + The actual JSON should be generated by the tooling, and this content can be replaced by + an include of the generated JSON. + + ```json + { + key: "A", + values = [ + { + value: "no" + description: "Attackers cannot reliably automate steps 1-4 of the kill chain for this vulnerability." + }, + { + value: "yes" + description: "Attackers can reliably automate steps 1-4 of the kill chain." + } + ], + } + ``` + + + +[*Automatable*](#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?" + + These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation. + +!!! question "When is Automatable *no*?" + + Reasons why a step may not be reliably automatable could include the following: + + 1. the vulnerable component is not searchable or enumerable on the network + 2. weaponization may require human direction for each target + 3. delivery may require channels that widely deployed network security configurations block + 4. exploitation is not reliable, due to exploit-prevention techniques (e.g., ASLR) enabled by default + + +!!! question "When is Automatable *yes*?" + + If the vulnerability allows remote code execution or command injection, the expected response should be yes. + + +Due to vulnerability chaining, there is some nuance as to whether reconnaissance can be automated. + +!!! 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. + 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). + 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). + + Like all SSVC decision points, [*Automatable*](#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. + diff --git a/docs/reference/decision_points/exploitation.md b/docs/reference/decision_points/exploitation.md new file mode 100644 index 00000000..a25d2e6b --- /dev/null +++ b/docs/reference/decision_points/exploitation.md @@ -0,0 +1,40 @@ +!!! note "Exploitation" + + Evidence of Active Exploitation of a Vulnerability + + | Value | Definition | + | :--- |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| + | None | There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability. | + | PoC
(Proof of Concept) | One of the following cases is true: (1) exploit code is sold or traded on underground or restricted fora; (2) a typical public PoC in places such as Metasploit or ExploitDB; or (3) the vulnerability has a well-known method of exploitation. Some examples of condition (3) are open-source web proxies serve as the PoC code for how to exploit any vulnerability in the vein of improper validation of TLS certificates. As another example, Wireshark serves as a PoC for packet replay attacks on ethernet or WiFi networks. A publicly-known hard-coded or default password would also meet this criteria. | + | Active | Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting. | + + +The intent of this measure is the present state of exploitation of the vulnerability. The intent is not to predict future exploitation but only to acknowledge the current state of affairs. Predictive systems, such as EPSS, could be used to augment this decision or to notify stakeholders of likely changes [@jacobs2021epss]. + +!!! 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. + For part (3), perhaps we could construct a mapping of CWE-IDs which always represent vulnerabilities with well-known methods of exploitation. + + !!! example "CWE-IDs for PoC" + + 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 the definition. + A comprehensive set of suggested CWE-IDs for this purpose is future work. + + Gathering information for [active](#exploitation) 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. + 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. + + The description for [none](#exploitation) 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)). diff --git a/docs/reference/decision_points/likely_decision_points.md b/docs/reference/decision_points/likely_decision_points.md new file mode 100644 index 00000000..75726022 --- /dev/null +++ b/docs/reference/decision_points/likely_decision_points.md @@ -0,0 +1,27 @@ +# Likely Decision Points and Relevant Data + +We propose the following decision points and associated values should be a factor when making decisions about +vulnerability prioritization. +{== Each decision point is tagged with the stakeholder it is relevant to: deployers, suppliers, or both. ==} +We emphasize that these descriptions are hypotheses to be further tested and validated. +We made every effort to put forward informed and useful decision frameworks with wide applicability, +but the goal of this paper is more to solicit feedback than make a declaration. We welcome questions, +constructive criticism, refuting evidence, or supporting evidence about any aspect of this proposal. + +!!! question "Where are the _Unknown_ options?" + + One important omission from the values for each category is an “unknown” option. + Instead, we recommend explicitly identifying an option that is a reasonable assumption based on prior events. + Such an option requires reliable historical evidence for what tends to be the case; + of course, future events may require changes to these assumptions over time. + Therefore, our assumptions require evidence and are open to debate in light of new evidence. + Different risk tolerance or risk discounting postures are not addressed in the current work; + accommodating such tolerance or discounting explicitly is an area for future work. + This flexibility fits into our overall goal of supplying a decision-making framework that is both transparent and fits + the needs of different communities. Resisting an “unknown” option discourages the modeler from silently embedding these + assumptions in their choices for how the decision tree flows below the selection of any “unknown” option. + +We propose satisfactory decision points for vulnerability management in the next sections, in no particular order. +Each section has a subsection with advice on gathering information about the decision point. +[SSVC using Current Information Sources](#ssvc-using-current-information-sources) will provide some suggestions about how existing sources of information about vulnerabilities can be used to collate responses to these decision points. + diff --git a/doc/md_src_files/05_07_mission_impact.md b/docs/reference/decision_points/mission_impact.md similarity index 79% rename from doc/md_src_files/05_07_mission_impact.md rename to docs/reference/decision_points/mission_impact.md index ada009e5..bcb443a5 100644 --- a/doc/md_src_files/05_07_mission_impact.md +++ b/docs/reference/decision_points/mission_impact.md @@ -1,5 +1,14 @@ -## Mission Impact -> Impact on Mission Essential Functions of the Organization +!!! note "Mission Impact" + + Impact on Mission Essential Functions of the Organization + + | Value | Description | + | :--- | :---------- | + | Degraded | Little to no impact up to degradation of non-essential functions; chronic degradation would eventually harm essential functions | + | MEF Support Crippled | Activities that directly support essential functions are crippled; essential functions continue for a time | + | MEF Failure | Any one mission essential function fails for period of time longer than acceptable; overall mission of the organization degraded but can still be accomplished for a time | + | Mission Failure | Multiple or all mission essential functions fail; ability to recover those functions degraded; organization’s ability to deliver its overall mission fails | + A **mission essential function (MEF)** is a function “directly related to accomplishing the organization’s mission as set forth in its statutory or executive charter” [@FCD2_2017, page A-1]. Identification and prioritization of mission essential functions enables effective continuity planning or crisis planning. @@ -19,14 +28,6 @@ Private sector businesses may better align with [operational and financial impac While the processes, terminology, and audience for these different frameworks differ, they all can provide a sense of the criticality of an asset or assets within the scope of the stakeholder conducting the cyber vulnerability prioritization with SSVC. In that sense they all function quite similarly within SSVC. Organizations should use whatever is most appropriate for their stakeholder context, with Mission Essential Function analysis serving as a fully worked example in the SSVC documents. -Table: Mission Impact Decision Values - -| Value | Definition | -| :--- | :---------- | -| Degraded | Little to no impact up to degradation of non-essential functions; chronic degradation would eventually harm essential functions | -| MEF Support Crippled | Activities that directly support essential functions are crippled; essential functions continue for a time | -| MEF Failure | Any one mission essential function fails for period of time longer than acceptable; overall mission of the organization degraded but can still be accomplished for a time | -| Mission Failure | Multiple or all mission essential functions fail; ability to recover those functions degraded; organization’s ability to deliver its overall mission fails | ### Gathering Information About Mission Impact diff --git a/docs/reference/decision_points/public_value_added.md b/docs/reference/decision_points/public_value_added.md new file mode 100644 index 00000000..7392c64a --- /dev/null +++ b/docs/reference/decision_points/public_value_added.md @@ -0,0 +1,18 @@ +!!! note "Public Value Added" + + This decision point asks how much value a publication from the coordinator would benefit the broader community. + The value is based on the state of existing public information about the vulnerablity. + + | Value | Description | + | :---: | :--- | + | 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. | + + +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. diff --git a/docs/reference/decision_points/report_credibility.md b/docs/reference/decision_points/report_credibility.md new file mode 100644 index 00000000..c1ea7180 --- /dev/null +++ b/docs/reference/decision_points/report_credibility.md @@ -0,0 +1,22 @@ +!!! note "Report Credibility" + + Assessing the credibility of a report is complex, but the assessment must reach a conclusion of either: + + | Value | Description | + | :---: | :--- | + | Credible | The report is credible. | + | Not credible | The report is not credible. | + + +!!! tip inline "See Also" + + Guidance on assessing credibility is available in [Credibility Indicators](../../topics/credibility_indicators.md). + +An analyst should start with a presumption of credibility and proceed toward disqualification. +The reason for this is that, as a coordinator, occasionally doing a bit of extra work on a bad report is preferable to rejecting legitimate reports. +This is essentially stating a preference for false positives over false negatives with respect to credibility determination. + +There are no ironclad rules for this assessment, and other coordinators may find other guidance works for them. +Credibility assessment topics include indicators for and against credibility, perspective, topic, and relationship to report scope. + + diff --git a/docs/reference/decision_points/report_public.md b/docs/reference/decision_points/report_public.md new file mode 100644 index 00000000..ed8ef39d --- /dev/null +++ b/docs/reference/decision_points/report_public.md @@ -0,0 +1,9 @@ +!!! note "Report Public" + + Is a viable report of the details of the vulnerability already publicly available? + + | Value | Description | + | :---: | :--- | + | Yes | A viable report of the details of the vulnerability is already publicly available. | + | No | A viable report of the details of the vulnerability is not already publicly available. | + diff --git a/doc/md_src_files/05_06_safety_impact.md b/docs/reference/decision_points/safety_impact.md similarity index 78% rename from doc/md_src_files/05_06_safety_impact.md rename to docs/reference/decision_points/safety_impact.md index e1c8af50..3b723990 100644 --- a/doc/md_src_files/05_06_safety_impact.md +++ b/docs/reference/decision_points/safety_impact.md @@ -1,5 +1,28 @@ -## Safety Impact -> Safety Impacts of Affected System Compromise +!!! note "Safety Impact" + + Safety Impacts of Affected System Compromise + + | Value | Type of Harm | Definition | + | --: | :-- | :----------- | + | None | All | Does *not* mean no impact *literally*; the effect is below the threshold for all aspects described in Minor | + | Minor | Physical Harm | Physical discomfort for users of the system OR a minor occupational safety hazard OR reduction in physical system safety margins | + | Minor | Environment | Minor externalities (property damage, environmental damage, etc.) imposed on other parties | + | Minor | Financial | Financial losses, which are not readily absorbable, to multiple persons | + | Minor | Psychological | Emotional or psychological harm, sufficient to be cause for counseling or therapy, to multiple persons | + | Major | Physical Harm | Physical distress and injuries for users of the system OR a significant occupational safety hazard OR failure of physical system functional capabilities that support safe operation | + | Major | Environment | Major externalities (property damage, environmental damage, etc.) imposed on other parties | + | Major | Financial | Financial losses that likely lead to bankruptcy of multiple persons | + | Major | Psychological | Widespread emotional or psychological harm, sufficient to be cause for counseling or therapy, to populations of people | + | Hazardous | Physical Harm | Serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures OR parts of the cyber-physical system that support safe operation break | + | Hazardous | Environment | Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties | + | Hazardous | Financial | Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state | + | Hazardous | Psychological | N/A | + | Catastrophic | Physical Harm | Multiple immediate fatalities (emergency response probably cannot save the victims.) | + | Catastrophic | Environment | Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties | + | Catastrophic | Financial | Social systems (elections, financial grid, etc.) supported by the software collapse | + | Catastrophic | Psychological | N/A | + + 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. -### Public Safety Impact - -Suppliers necessarily have a rather coarse-grained perspective on the broadly defined safety impacts described above. Therefore we simplify the above into a binary categorization: _Significant_ is when any impact meets the criteria for an impact of Major, Hazardous, or Catastrophic in the above table. _Minimal_ is when none do. - -Table: Public Safety Impact Decision Values - -| Value | Definition | -| :--- | :--------- | -| Minimal | Safety Impact of None or Minor | -| Significant | Safety Impact of Major, Hazardous, or Catastrophic | - ### Situated Safety Impact diff --git a/docs/reference/decision_points/supplier_cardinality.md b/docs/reference/decision_points/supplier_cardinality.md new file mode 100644 index 00000000..887642cb --- /dev/null +++ b/docs/reference/decision_points/supplier_cardinality.md @@ -0,0 +1,8 @@ +!!! note "Supplier Cardinality" + + How many suppliers are responsible for the vulnerable component and its remediation or mitigation plan? + + | Value | Description | + | :---: | :--- | + | One | One supplier is responsible for the vulnerable component and its remediation or mitigation plan. | + | Multiple | Multiple suppliers are responsible for the vulnerable component and its remediation or mitigation plan. | diff --git a/docs/reference/decision_points/supplier_contacted.md b/docs/reference/decision_points/supplier_contacted.md new file mode 100644 index 00000000..40e473e7 --- /dev/null +++ b/docs/reference/decision_points/supplier_contacted.md @@ -0,0 +1,14 @@ +!!! tip inline end "Quality Contact Method" + + A quality contact method is a publicly posted known good email address, public portal on vendor website, etc. + + +!!! note "Supplier Contacted" + + Has the reporter made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method? + + | Value | Description | + | :---: | :--- | + | Yes | The reporter has made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method. | + | No | The reporter has not made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method. | + diff --git a/docs/reference/decision_points/supplier_engagement.md b/docs/reference/decision_points/supplier_engagement.md new file mode 100644 index 00000000..ddb820cb --- /dev/null +++ b/docs/reference/decision_points/supplier_engagement.md @@ -0,0 +1,9 @@ +!!! note "Supplier Engagement" + + Is the supplier responding to the reporter's contact effort and actively participating in the coordination effort? + + | Value | Description | + | :---: | :--- | + | Active | The supplier is responding to the reporter's contact effort and actively participating in the coordination effort. | + | Unresponsive | The supplier is not responding to the reporter's contact effort and is not actively participating in the coordination effort. | + diff --git a/docs/reference/decision_points/supplier_involvement.md b/docs/reference/decision_points/supplier_involvement.md new file mode 100644 index 00000000..3a0ee4b3 --- /dev/null +++ b/docs/reference/decision_points/supplier_involvement.md @@ -0,0 +1,10 @@ + +!!! note "Supplier Involvement" + + This decision point accounts for the state of the supplier's work on addressing the vulnerability. + + | Value | Description | + | :---: | :--- | + | Fix Ready | The supplier has provided a patch or fix. | + | Cooperative | The supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time. | + | Uncooperative/Unresponsive | The supplier has not responded, declined to generate a remediation, or no longer exists. | diff --git a/doc/md_src_files/05_09_system_exposure.md b/docs/reference/decision_points/system_exposure.md similarity index 78% rename from doc/md_src_files/05_09_system_exposure.md rename to docs/reference/decision_points/system_exposure.md index e0190db4..aae67216 100644 --- a/doc/md_src_files/05_09_system_exposure.md +++ b/docs/reference/decision_points/system_exposure.md @@ -1,5 +1,12 @@ -## System Exposure -> The Accessible Attack Surface of the Affected System or Service +!!! note "System Exposure" + + The Accessible Attack Surface of the Affected System or Service + + | Value | Description | + | :--- | :------------ | + | Small | Local service or program; highly controlled network | + | Controlled | Networked service with some access restrictions or mitigations already in place (whether locally or on the network). A successful mitigation must reliably interrupt the adversary’s attack, which requires the attack is detectable both reliably and quickly enough to respond. *Controlled* covers the situation in which a vulnerability can be exploited through chaining it with other vulnerabilities. The assumption is that the number of steps in the attack path is relatively low; if the path is long enough that it is implausible for an adversary to reliably execute it, then *exposure* should be *small*. | + | Open | Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers) | Measuring the attack surface precisely is difficult, and we do not propose to perfectly delineate between small and controlled access. Exposure should be judged against the system in its deployed context, which may differ from how it is commonly expected to be deployed. @@ -11,13 +18,6 @@ Therefore, a deployer’s response to Exposure may change if such mitigations ar If a mitigation changes exposure and thereby reduces the priority of a vulnerability, that mitigation can be considered a success. Whether that mitigation allows the deployer to defer further action varies according to each case. -Table: System Exposure Decision Values - -| Value | Definition | -| :--- | :------------ | -| Small | Local service or program; highly controlled network | -| Controlled | Networked service with some access restrictions or mitigations already in place (whether locally or on the network). A successful mitigation must reliably interrupt the adversary’s attack, which requires the attack is detectable both reliably and quickly enough to respond. *Controlled* covers the situation in which a vulnerability can be exploited through chaining it with other vulnerabilities. The assumption is that the number of steps in the attack path is relatively low; if the path is long enough that it is implausible for an adversary to reliably execute it, then *exposure* should be *small*. | -| Open | Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers) | ### Gathering Information About System Exposure diff --git a/docs/reference/decision_points/technical_impact.md b/docs/reference/decision_points/technical_impact.md new file mode 100644 index 00000000..847e00f4 --- /dev/null +++ b/docs/reference/decision_points/technical_impact.md @@ -0,0 +1,34 @@ +!!! note "Technical Impact" + + Technical Impact of Exploiting the Vulnerability + + | Value | Definition | + | :--- | :------------- | + | Partial | The exploit gives the adversary *limited* control over, or information exposure about, the behavior of the software that contains the vulnerability. Or the exploit gives the adversary an importantly low stochastic opportunity for total control. In this context, “low” means that the attacker cannot reasonably make enough attempts to overcome the low chance of each attempt not working. Denial of service is a form of limited control over the behavior of the vulnerable component. | + | Total | The exploit gives the adversary *total* control over the behavior of the software, or it gives total disclosure of all information on the system that contains the vulnerability | + +When evaluating [*Technical Impact*](#technical-impact), recall the scope definition in the [Scope Section](#scope). +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. +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. + + +!!! 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. + 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*. + After exploiting the vulnerability, + + - can the attacker install and run arbitrary software? + - can the attacker trigger all the actions that the vulnerable component can perform? + - 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). + diff --git a/docs/reference/decision_points/value_density.md b/docs/reference/decision_points/value_density.md new file mode 100644 index 00000000..f0ca68a6 --- /dev/null +++ b/docs/reference/decision_points/value_density.md @@ -0,0 +1,46 @@ +!!! note "Value Density" + + [*Value Density*](#value-density) is described as *diffuse* or *concentrated* based on the resources that the adversary will gain control over with a single exploitation event: + + | Value | Definition | + | :--- | :---------- | + | diffuse | The system that contains the vulnerable component has limited resources. That is, the resources that the adversary will gain control over with a single exploitation event are relatively small.| + | concentrated | The system that contains the vulnerable component is rich in resources. Heuristically, such systems are often the direct responsibility of “system operators” rather than users. | + +!!! info inline end "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 + the proper operation or maintenance of a system. + +!!! example "Diffuse" + + Examples of systems with diffuse value are email accounts, most consumer online banking accounts, common cell + phones, and most personal computing resources owned and maintained by users. + +!!! example "Concentrated" + + Examples of concentrated value are database systems, Kerberos + servers, web servers hosting login pages, and cloud service + providers. However, usefulness and uniqueness of the resources on + the vulnerable system also inform value density. For example, + encrypted mobile messaging platforms may have concentrated value, + not because each phone’s messaging history has a particularly large + amount of data, but because it is uniquely valuable to law + enforcement. + +!!! 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). + 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. + Organizations such as Gartner produce research on the market position and product comparisons for a large variety of systems. + These generally identify how a product is deployed, used, and maintained. + An organization's own marketing materials are a less reliable indicator of how a product is used, or at least how the organization expects it to be used. + + Network telemetry can inform how many instances of a software system are connected to a network. + 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. diff --git a/docs/reference/index.md b/docs/reference/index.md new file mode 100644 index 00000000..b3970a20 --- /dev/null +++ b/docs/reference/index.md @@ -0,0 +1,12 @@ +# SSVC Reference + +!!! note "TODO: What should go here?" + + - a list of all the decision points, values, and versions + - decision point versioning rules + - outcome versioning rules + - tree versioning rules (if applicable) + - a list of outcome values and versions + - code documentation + - ssvc calc app + - python modules \ No newline at end of file diff --git a/ssvc-calc/CISA-Coordinator.json b/docs/ssvc-calc/CISA-Coordinator.json similarity index 100% rename from ssvc-calc/CISA-Coordinator.json rename to docs/ssvc-calc/CISA-Coordinator.json diff --git a/ssvc-calc/Coordinator-Publish.json b/docs/ssvc-calc/Coordinator-Publish.json similarity index 100% rename from ssvc-calc/Coordinator-Publish.json rename to docs/ssvc-calc/Coordinator-Publish.json diff --git a/ssvc-calc/Coordinator-Triage.json b/docs/ssvc-calc/Coordinator-Triage.json similarity index 100% rename from ssvc-calc/Coordinator-Triage.json rename to docs/ssvc-calc/Coordinator-Triage.json diff --git a/ssvc-calc/Deployer.json b/docs/ssvc-calc/Deployer.json similarity index 100% rename from ssvc-calc/Deployer.json rename to docs/ssvc-calc/Deployer.json diff --git a/ssvc-calc/README.md b/docs/ssvc-calc/README.md similarity index 100% rename from ssvc-calc/README.md rename to docs/ssvc-calc/README.md diff --git a/docs/ssvc-calc/SSVC_Computed.schema.json b/docs/ssvc-calc/SSVC_Computed.schema.json new file mode 120000 index 00000000..a69880fc --- /dev/null +++ b/docs/ssvc-calc/SSVC_Computed.schema.json @@ -0,0 +1 @@ +../../data/schema/SSVC_Computed.schema.json \ No newline at end of file diff --git a/docs/ssvc-calc/SSVC_Provision.schema.json b/docs/ssvc-calc/SSVC_Provision.schema.json new file mode 120000 index 00000000..813701f5 --- /dev/null +++ b/docs/ssvc-calc/SSVC_Provision.schema.json @@ -0,0 +1 @@ +../../data/schema/SSVC_Provision.schema.json \ No newline at end of file diff --git a/ssvc-calc/Supplier.json b/docs/ssvc-calc/Supplier.json similarity index 100% rename from ssvc-calc/Supplier.json rename to docs/ssvc-calc/Supplier.json diff --git a/ssvc-calc/cmu-logo.png b/docs/ssvc-calc/cmu-logo.png similarity index 100% rename from ssvc-calc/cmu-logo.png rename to docs/ssvc-calc/cmu-logo.png diff --git a/ssvc-calc/css.css b/docs/ssvc-calc/css.css similarity index 100% rename from ssvc-calc/css.css rename to docs/ssvc-calc/css.css diff --git a/ssvc-calc/icons8-copy-60.png b/docs/ssvc-calc/icons8-copy-60.png similarity index 100% rename from ssvc-calc/icons8-copy-60.png rename to docs/ssvc-calc/icons8-copy-60.png diff --git a/ssvc-calc/icons8-copy-link-48.png b/docs/ssvc-calc/icons8-copy-link-48.png similarity index 100% rename from ssvc-calc/icons8-copy-link-48.png rename to docs/ssvc-calc/icons8-copy-link-48.png diff --git a/ssvc-calc/index.html b/docs/ssvc-calc/index.html similarity index 99% rename from ssvc-calc/index.html rename to docs/ssvc-calc/index.html index bdfc662b..32b1e3d6 100644 --- a/ssvc-calc/index.html +++ b/docs/ssvc-calc/index.html @@ -34,7 +34,7 @@ CERT Logo + onclick="$('body').toggleClass('blackbody').toggleClass('whitebody')"/>
@@ -57,7 +57,7 @@

CMU Logo + style="visibility:hidden"/>

\ 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..3d19e7c1 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('../../../data/csvs/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/index.md b/docs/topics/index.md index 87bf8dd5..16328d4d 100644 --- a/docs/topics/index.md +++ b/docs/topics/index.md @@ -85,7 +85,6 @@ The remainder of this section is organized as follows: - :material-state-machine: [**Current State of Practice**](state_of_practice.md) - :material-information-box-outline: [**Representing Information for Decisions About Vulnerabilities**](representing_information.md) - :material-arrow-decision: [**Vulnerability Management Decisions**](vulnerability_management_decisions.md) -- :material-group: [**Compound Decision Points**](compound_decision_points.md) - :material-file-document-check-outline: [**Worked Example**](worked_example.md) - :material-checkbox-marked-outline: [**Evaluation**](evaluation_of_draft_trees.md) - :material-relation-one-to-many: [**Related Systems**](related_systems.md) 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 efbbe567..dc6d2905 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -69,11 +69,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' @@ -86,7 +86,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' From 529b77943e8a3035c14acf8afe2fc78368e65201 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 15 Feb 2024 12:21:24 -0500 Subject: [PATCH 073/113] Create link_checker.yml (#465) Adds a github workflow that builds the site and checks links anytime a PR wants to change a markdown file. --- .github/workflows/link_checker.yml | 41 ++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 .github/workflows/link_checker.yml 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 + From ad38ddbd02db40613461bf61ef4cee4f38f40aee Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 15 Feb 2024 12:46:09 -0500 Subject: [PATCH 074/113] fix how we load csv files (#470) --- docs/howto/coordination_decisions.md | 3 ++- docs/howto/deployer_tree.md | 3 ++- docs/howto/publication_decision.md | 3 ++- docs/howto/supplier_tree.md | 3 ++- docs/reference/decision_points/exploitation.md | 4 ++-- mkdocs.yml | 3 ++- 6 files changed, 12 insertions(+), 7 deletions(-) diff --git a/docs/howto/coordination_decisions.md b/docs/howto/coordination_decisions.md index 309c9906..0e6415d2 100644 --- a/docs/howto/coordination_decisions.md +++ b/docs/howto/coordination_decisions.md @@ -43,4 +43,5 @@ Other coordinators should consider customizing the tree to their needs, as descr ### Table of Values -{{ read_csv('../../data/csvs/coord-triage-options.csv') }} + +{{ read_csv('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/publication_decision.md b/docs/howto/publication_decision.md index 45bbdb05..3b7c4afc 100644 --- a/docs/howto/publication_decision.md +++ b/docs/howto/publication_decision.md @@ -158,5 +158,6 @@ flowchart LR ### Table of Values -{{ read_csv('../../data/csvs/coord-publish-options.csv') }} + +{{ 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/reference/decision_points/exploitation.md b/docs/reference/decision_points/exploitation.md index 3d19e7c1..4b99c7ec 100644 --- a/docs/reference/decision_points/exploitation.md +++ b/docs/reference/decision_points/exploitation.md @@ -40,7 +40,7 @@ The table below lists CWE-IDs that could be used to mark a vulnerability as *PoC 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/mkdocs.yml b/mkdocs.yml index dc6d2905..4d4d49d0 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -111,7 +111,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: From ab841725332c2b2348d49ea2d460306b06f23031 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 15 Feb 2024 12:52:33 -0500 Subject: [PATCH 075/113] add linkchecker status badge to README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0e3d8c06..5eb5b90a 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)](https://github.com/CERTCC/SSVC/actions/workflows/link_checker.yml) # SSVC From e6cb9d5d14436a8233e72fc663f6f175c1594714 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 15 Feb 2024 12:53:46 -0500 Subject: [PATCH 076/113] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 5eb5b90a..6838e477 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -[![Link Checker](https://github.com/CERTCC/SSVC/actions/workflows/link_checker.yml/badge.svg)](https://github.com/CERTCC/SSVC/actions/workflows/link_checker.yml) +[![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 From ad427b3afd77af5cf6aad1b7b0b58b516abbbf69 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 15 Feb 2024 13:22:50 -0500 Subject: [PATCH 077/113] Add building block analogy explainer (#447) * add links * add to nav * update enumerating_decisions.md * update top-level topics overview to include bricks page * adjust `discreteness` words to reflect interface with data/other bricks --- docs/topics/decision_points_as_bricks.md | 107 +++++++++++++++++++++++ docs/topics/enumerating_decisions.md | 4 +- docs/topics/index.md | 1 + mkdocs.yml | 1 + 4 files changed, 111 insertions(+), 2 deletions(-) create mode 100644 docs/topics/decision_points_as_bricks.md diff --git a/docs/topics/decision_points_as_bricks.md b/docs/topics/decision_points_as_bricks.md new file mode 100644 index 00000000..227f6c8f --- /dev/null +++ b/docs/topics/decision_points_as_bricks.md @@ -0,0 +1,107 @@ +# Putting the Pieces Together + +As we have continued to refine our concept of SSVC, we have an increasing understanding of the importance of +[_Decision Points_](../reference/decision_points/index.md) as the foundational blocks from which the rest of the +SSVC concept is built. A second, but less foundational, concept are the [_Outcomes_](../reference/code/outcomes.md) that +provide a vocabulary to describe the results of a decision. + +## Decision Points and Outcomes as Bricks + +Over time, we have come to think of decision points and outcomes as the LEGO® bricks of SSVC decision models. + +!!! info inline end "LEGO® Bricks" + + LEGO® is a trademark of the [LEGO](https://www.lego.com/) Group of companies which does not sponsor, authorize or endorse this site. + +LEGO® Bricks come in different shapes and sizes, and they can be combined in different ways to build different structures. +Similarly, decision points come in different shapes and sizes, and they can be combined in different ways to build +different decision models. +And just as some bricks can be substituted for others to add variation, some decision points are substitutable for others. + +We have realized that part of the value of enumerated decision points is that they provide a way to organize the information that is +relevant to a decision. This organization is important because it helps us to understand the decision and to communicate +the decision model to others. + +Decision points and outcomes have a few key characteristics that make them useful for organizing information: + +- **Independence**: Each decision point represents a different aspect or dimension of the decision being modeled. This means that + the decision points are not redundant with each other. They may each be relevant to the decision, but they are relevant + in different ways. +- **Discreteness**: Each decision point has a finite and discrete set of possible values. These specific values + that can then be mapped onto data collection and analysis results so that the data can be used to inform the decision. +- **Well-Definedness**: Each decision point has a clear meaning and a clear, ordered set of possible values. This means that the decision + point values are not ambiguous or open to interpretation. + +In our brick analogy, the toy bricks are similarly independent, discrete, and well-defined. +Independence means that different bricks can serve different purposes in the model. +The pips on the bricks provide discrete points of attachment to allow bricks to connect together. +Well-definedness (specification and manufacturing consistency) allows bricks to be combined effectively. + +## Model Kits and How to Use Them + +When you buy a model kit at the store, you get + +- a box with a picture of the model on the front, and sometimes variation suggestions on the back +- a set of bricks, usually organized into bags appropriate for the different stages of the build +- a set of instructions to tell you how to combine the bricks to build the model(s) pictured on the box + +From that starting point, there are a few different ways you might proceed: + +### Follow the examples as provided + +For many people, this is the experience they want. +They want to build the model exactly as it is pictured on the box, and for that purpose they can follow the instructions provided. + +### Adapt the examples to suit your needs + +But other folks might want to build something else with the bricks. +They might want to adapt the model slightly for their own purposes, perhaps turning an airplane with wheels into a seaplane by adding floats, or turning a car into a spaceship by adding a rocket booster. +To do that, they might follow the instructions provided, just adapting them slightly with their own variations. +Sometimes they might add a few extra bricks from their own collection to make the model more like what they want. + +### Combine different kits to build something new + +Perhaps they might want to combine two different model kits to build something new. +Knowing which parts of the instructions to follow and which parts to ignore is a matter of understanding the properties +of the bricks and the context of the model they want to build. + +### Build something completely original + +A builder might want to create something completely new that is not available in kit form, like a castle guarded by robots. +In that scenario, they might think of the kit more as a supply of specific bricks than as a specific model. +Advanced builders need to understand more about what they are trying to build and how the bricks can be combined to build it. + +The point is that the model kits serve as a starting point with a lot of flexibility, but it is up to the builder +to decide how much of that flexibility to use. + +## SSVC Decision Models as Kits + +Similarly, SSVC provides a set of "bricks" in the form of [decision points](../reference/decision_points/index.md) +and [outcomes](../reference/code/outcomes.md). +We have provided a set of [example decision models](../howto/index.md) and [policies](../howto/index.md) to get you started. +You might choose to simply use what we've provided as a starting point. +Or you might already recognize that our example gets the structure of the decision model right, +but you need to adapt the outcomes or policy to better fit your situation. + +You might also recognize that you need to combine different example decision models to build the model you need. +For example, you might recognize that you need to combine the [supplier decision model](../howto/supplier_tree.md) +with the [deployer decision model](../howto/deployer_tree.md) to +build a model that is relevant to your situation as both a supplier and a deployer. + +Or, perhaps you have a decision problem that we have not yet addressed with any of our examples. +In that case, you might examine the [decision points](../reference/decision_points/index.md) we've provided and +decide which ones are relevant to your situation. +You could choose to customize a decision point to better fit your situation, or you might choose to add a new decision point +to better suit your needs. + +This is the embodiment of the _Stakeholder-Specific_ concept in [SSVC](../index.md): +SSVC provides the components for you to build your own decision models, and we provide some examples to get you started. +If the examples are sufficient for your needs, then you can simply use them as they are. + +But we recognize that you are the expert in your own situation, and that you are in a better position than we are to +decide how to combine the provided components to build the decision model you need. +If you need to adapt the components we've provided, or if you need to add new components, then we encourage you to do so. +And if you think that your adaptations or additions would be useful to others, then we encourage you to share your +[suggestions](https://github.com/CERTCC/SSVC/issues), [ideas](https://github.com/CERTCC/SSVC/discussions), and +[changes](https://github.com/CERTCC/SSVC/pulls) with the [community](https://github.com/CERTCC/SSVC). + diff --git a/docs/topics/enumerating_decisions.md b/docs/topics/enumerating_decisions.md index f2e1e0ef..d0395def 100644 --- a/docs/topics/enumerating_decisions.md +++ b/docs/topics/enumerating_decisions.md @@ -1,7 +1,7 @@ # Enumerating Decisions Stakeholders with different responsibilities in vulnerability management have very different decisions to make. -{== This section ==} focuses on the differences among organizations based on their vulnerability management responsibilities. +This section focuses on the differences among organizations based on their vulnerability management responsibilities. Some decision makers may have different responsibilities in relation to different software. !!! example "Example: Different Responsibilities for Different Software" @@ -24,4 +24,4 @@ we recommend that the professionals making genuine decisions do three things: 2. describe how they view their role(s) 3. identify which software projects their decision relates to -If their decisions are explicit, then the decision makers can use the recommendations from this document that are relevant to them. +If their decisions are explicit, then the decision makers can use the recommendations from this documentation that are relevant to them. diff --git a/docs/topics/index.md b/docs/topics/index.md index 16328d4d..db7b8655 100644 --- a/docs/topics/index.md +++ b/docs/topics/index.md @@ -85,6 +85,7 @@ The remainder of this section is organized as follows: - :material-state-machine: [**Current State of Practice**](state_of_practice.md) - :material-information-box-outline: [**Representing Information for Decisions About Vulnerabilities**](representing_information.md) - :material-arrow-decision: [**Vulnerability Management Decisions**](vulnerability_management_decisions.md) +- :material-toy-brick-outline: [**Putting the Pieces Together**](decision_points_as_bricks.md) - :material-file-document-check-outline: [**Worked Example**](worked_example.md) - :material-checkbox-marked-outline: [**Evaluation**](evaluation_of_draft_trees.md) - :material-relation-one-to-many: [**Related Systems**](related_systems.md) diff --git a/mkdocs.yml b/mkdocs.yml index 4d4d49d0..2d96ab82 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -22,6 +22,7 @@ nav: - Risk Tolerance and Priority: 'topics/risk_tolerance_and_priority.md' - Scope: 'topics/scope.md' - SSVC and Asset Management: 'topics/asset_management.md' + - Putting the Pieces Together: 'topics/decision_points_as_bricks.md' - Worked Example: 'topics/worked_example.md' - Evaluation: 'topics/evaluation_of_draft_trees.md' - Related Systems: 'topics/related_systems.md' From 6f9ac8b4bc60270817237ba4c60bbe0668bcabd7 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Sat, 17 Feb 2024 00:08:12 -0500 Subject: [PATCH 078/113] revise index.md (#469) --- docs/howto/index.md | 39 ++++++++++++++++++++++++++------------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/docs/howto/index.md b/docs/howto/index.md index bf6b5090..a9ed4093 100644 --- a/docs/howto/index.md +++ b/docs/howto/index.md @@ -11,7 +11,8 @@ [Understanding SSVC](../topics/index.md) section, which provides necessary background detail. For technical reference, see [Reference](../reference/index.md). -!!! note "TODO: What should go here?" + -## 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. +Given a specific [stakeholder](../topics/enumerating_stakeholders.md) [decision](../topics/enumerating_decisions.md) +and set of useful [decision points](../reference/decision_points/index.md), +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)) + - ([*Exploitation*](../reference/decision_points/exploitation.md) IS *Public PoC*) AND + - ([*System Exposure*](../reference/decision_points/system_exposure.md) IS *controlled*) AND + - ([*Automatable*](../reference/decision_points/automatable.md) IS *no*) AND + - ([*Human Impact*](../reference/decision_points/human_impact.md) IS *medium*) - 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]. +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). +In this documentation, 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 various stakeholders, followed by guidance on how to adapt and customize SSVC to +fit your organization's needs. + +
+ +- :material-factory: [Supplier Decision Model](supplier_tree.md) +- :material-server-network: [Deployer Decision Model](deployer_tree.md) +- :material-steering: [Coordinator Decision Models](coordination_intro.md) +- :material-stairs: [Bootstrapping SSVC](bootstrap/index.md) +- :material-hand-saw: [Customizing SSVC](tree_customization.md) +- :material-slope-uphill: [Acuity Ramp](acuity_ramp.md) +
From 4aff9d757bf54d4b462fafc58055fd54db64a911 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Sat, 17 Feb 2024 00:08:29 -0500 Subject: [PATCH 079/113] expand SSVC acronym in site name (#474) --- mkdocs.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mkdocs.yml b/mkdocs.yml index 2d96ab82..5f0e7994 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,4 +1,4 @@ -site_name: SSVC +site_name: "SSVC: Stakeholder-Specific Vulnerability Categorization" copyright: Copyright © 2024 Carnegie Mellon University. nav: - Home: 'index.md' From 06a943bf0d32659b62410f7c486bba2f5f2d157a Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Sat, 17 Feb 2024 00:09:41 -0500 Subject: [PATCH 080/113] Add community engagement links (#468) --- .github/ISSUE_TEMPLATE/bug_report.md | 30 ++++++++++++ .github/ISSUE_TEMPLATE/feature_request.md | 20 ++++++++ .github/ISSUE_TEMPLATE/question.md | 12 +++++ CONTRIBUTING.md | 42 +---------------- docs/_includes/helping_out.md | 57 +++++++++++++++++++++++ docs/about/contact_us.md | 3 +- docs/about/contributing.md | 2 + docs/about/index.md | 16 ++++--- docs/index.md | 5 +- mkdocs.yml | 18 +++++-- 10 files changed, 151 insertions(+), 54 deletions(-) create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md create mode 100644 .github/ISSUE_TEMPLATE/feature_request.md create mode 100644 .github/ISSUE_TEMPLATE/question.md create mode 100644 docs/_includes/helping_out.md diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 00000000..eb1641c5 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,30 @@ +--- +name: Bug report +about: Create a report to help us improve +title: Add a brief title for your report here +labels: bug +assignees: '' + +--- + +**Describe the bug** +A clear and concise description of what the bug is. + +**To Reproduce** +Steps to reproduce the behavior: +1. Go to '...' +2. Click on '....' +3. Scroll down to '....' +4. See error + +**Expected behavior** +A clear and concise description of what you expected to happen. + +**Screenshots** +If applicable, add screenshots to help explain your problem. + +**Platform details** +Include any relevant details like OS, browser, versions, etc. + +**Additional context** +Add any other context about the problem here. diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md new file mode 100644 index 00000000..c365d3de --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -0,0 +1,20 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: Add a concise title for your request +labels: enhancement +assignees: '' + +--- + +**Is your feature request related to a problem? Please describe.** +A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] + +**Describe the solution you'd like** +A clear and concise description of what you want to happen. + +**Describe alternatives you've considered** +A clear and concise description of any alternative solutions or features you've considered. + +**Additional context** +Add any other context or screenshots about the feature request here. diff --git a/.github/ISSUE_TEMPLATE/question.md b/.github/ISSUE_TEMPLATE/question.md new file mode 100644 index 00000000..83c47536 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/question.md @@ -0,0 +1,12 @@ +--- +name: Question +about: Ask the SSVC team a question +title: Add a concise title for your question +labels: question +assignees: '' + +--- + +_Note:_ Questions for the SSVC team can be asked here in the form of an issue. More general questions directed at the SSVC user community +might be a better fit in the [Q&A](https://github.com/CERTCC/SSVC/discussions/categories/q-a) category of our +[Discussions](https://github.com/CERTCC/SSVC/discussions) area. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 89b43480..8838e46d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -6,50 +6,12 @@ To account for different stakeholder perspectives, we benefit from a diverse gro Please see our project documentation in the [wiki](https://github.com/CERTCC/SSVC/wiki) that accompanies this repository for more information on how you can contribute to the project. -## Where to contribute - -This repository contains both a written document with the English-langauge spec, and some code for automating application of SSVC. -Contributions to these two parts of the project look different. -We are focusing on getting the English right first, so we know what code to write. -Right now we don't have any plans for translations, but if you have interest in that [let us know](https://github.com/CERTCC/SSVC/issues/123). - -# Contributing to the document - -The English text lives in the `docs` [subfolder](https://github.com/CERTCC/SSVC/tree/main/docs). -We welcome any issues from anyone in the community, so we can discuss them and improve SSVC. -If you have a suggestion, please [create an issue](https://github.com/CERTCC/SSVC/issues/new/choose). - -In general, please create an issue before making a pull request to submit a change, except in the case of fixing a small -typo, etc. -Please check that your suggestion does not overlap with existing [issues](https://github.com/CERTCC/SSVC/issues) -(including [closed ones](https://github.com/CERTCC/SSVC/issues?q=is%3Aissue+is%3Aclosed+)) - -Please see the [SSVC project wiki]([wiki](https://github.com/CERTCC/SSVC/wiki) for how to keep any -suggestions or commits aligned with our style consistently. - -# Contributing code - -The tools for working with SSVC live in the `src` [subfolder](https://github.com/CERTCC/SSVC/tree/main/src). - -We have limited tooling at the moment. The expectation is that these will mostly be flexible helper-type scripts and plug-ins. -Therefore, interoperability is important. -Where the code implements or directly references some aspect of the English document, please make that linkage explicit. -We use config files stored in `data` to prevent code in `src` from having fragile dependencies on the English doc. -We would like to minimize manual change management, but at the very least we need to document where changes in the -document need to result in changes to code. -Information likely to change based on changes to the English should go in config files to be stored in the -`data` [subfolder](https://github.com/CERTCC/SSVC/tree/main/data). -Code in the `src` folder should (as robustly as plausible) be reading that data in. - -The process is similar to that for the doc, though the language is different. Please create issues before making pull requests. -Pull requests on code should be clear about what they've changed and what you've done. Thanks in advance! - -# Licenses +## Licenses - The license for all code in the repository is [here](https://github.com/CERTCC/SSVC/blob/main/LICENSE) - The license for all English writing in the repository is [here](https://github.com/CERTCC/SSVC/blob/main/doc/version_1/900_license.md) -# Questions +## Questions If you have any questions, an [issue](https://github.com/CERTCC/SSVC/issues) or [discussion](https://github.com/CERTCC/SSVC/discussions) is the best way to get in touch with us. diff --git a/docs/_includes/helping_out.md b/docs/_includes/helping_out.md new file mode 100644 index 00000000..e8885c48 --- /dev/null +++ b/docs/_includes/helping_out.md @@ -0,0 +1,57 @@ +# How Can I Engage with the SSVC Community? + +We welcome your feedback and contributions to SSVC. Here are some ways you can get involved: + +
+ +- :material-message-question: _Ask a question_ + + --- + + If you have a specific question for the SSVC team, please feel free to + [Ask a Question](https://github.com/CERTCC/SSVC/issues/new?template=question.md). + + Questions of more general interest to the community of SSVC users might fit better in the + [Q&A](https://github.com/CERTCC/SSVC/discussions/categories/q-a) section of the + [Discussion](https://github.com/CERTCC/SSVC/discussions) area. + +- :fontawesome-solid-bug: _Report a problem_ + + --- + + If you find a problem with the SSVC documentation, the methodology, or accompanying code, we + welcome your [Bug Reports](https://github.com/CERTCC/SSVC/issues/new?template=bug_report.md) + +- :material-lightbulb-on: _Suggest an improvement_ + + --- + Got an idea for how to make SSVC better? We'd love to hear it! Please submit your + [Feature Requests](https://github.com/CERTCC/SSVC/issues/new?template=feature_request.md) + +- :fontawesome-regular-comments: _Join the conversation_ + + --- + + More in-depth conversations that might not be actionable as issues are found in the + [Discussions](https://github.com/CERTCC/SSVC/discussions) area. + +- :material-binoculars: _See what we're working on_ + + --- + + We manage the SSVC development effort via Github [Issues](https://github.com/CERTCC/SSVC/issues) and + [Pull Requests](https://github.com/CERTCC/SSVC/pulls). + Drop by and see what we're working on, or leave a comment to let us know what you're interested in. + +- :material-hub: _Get more involved_ + + --- + + Want more information about engaging as a collaborator? Check out the [SSVC Project Wiki](https://github.com/CERTCC/SSVC/wiki) + +
+ + +!!! tip "Footer Icons" + + The icons in the footer of each page also provide links to engage with the SSVC community. diff --git a/docs/about/contact_us.md b/docs/about/contact_us.md index 63fc35de..3e740193 100644 --- a/docs/about/contact_us.md +++ b/docs/about/contact_us.md @@ -1,4 +1,3 @@ - # Contact Us Software Engineering Institute @@ -7,3 +6,5 @@ Software Engineering Institute **Phone**: 412.268.5800 | 888.201.4479 **Web**: [www.sei.cmu.edu](http://www.sei.cmu.edu) **Email**: [info@sei.cmu.edu](mailto:info@sei.cmu.edu) + +{% include-markdown "../_includes/helping_out.md" heading-offset=1 %} \ No newline at end of file diff --git a/docs/about/contributing.md b/docs/about/contributing.md index 3f0c5a8a..fdd0519e 100644 --- a/docs/about/contributing.md +++ b/docs/about/contributing.md @@ -1 +1,3 @@ +{% include-markdown "../_includes/helping_out.md" %} + {% include-markdown "../../CONTRIBUTING.md" %} \ No newline at end of file diff --git a/docs/about/index.md b/docs/about/index.md index b393cda6..74f4fc02 100644 --- a/docs/about/index.md +++ b/docs/about/index.md @@ -1,20 +1,22 @@ # About SSVC -SSVC version 2 presents a method for suppliers, deployers, and coordinators to use to prioritize their effort to mitigate vulnerabilities. -We have built on SSVC version 1 through public presentation and feedback, private consultation, and continued analyst testing. -The evaluation process we developed in version 1 remains an important part of continued improvement of SSVC, and will be used to continue refinements of SSVC version 2. -We invite participation and further refinement of the prioritization mechanism from the community as well, such as by [posting an issue](https://github.com/CERTCC/SSVC/issues). +SSVC presents a method for suppliers, deployers, and coordinators to use to prioritize their effort to mitigate vulnerabilities. +We have built on previous SSVC versions through public presentation and feedback, private consultation, and continued analyst testing. +The evaluation process we developed in version 1 remains an important part of continued improvement of SSVC, and will be used to continue refinements of SSVC going forward. +We invite [participation](contributing.md) and further refinement of the prioritization mechanism from the community as well, such as by [posting an issue](https://github.com/CERTCC/SSVC/issues). We endeavored to be transparent about our process and provide justification for design decisions. -We invite questions, comments, and further community refinement in moving forward with a transparent and justified vulnerability prioritization methodology that is inclusive for the various stakeholders and industries that develop and use information and computer technology. +We invite questions, comments, and further community refinement in moving forward with a transparent and justified +vulnerability prioritization methodology that is inclusive for the various stakeholders and industries that develop +and use information and computer technology.
+- :material-offer: [Community Engagement](contributing.md) +- :material-arrow-decision: [Decision Records](../adr/index.md) - :material-handshake: [Acknowledgements](acknowledgements.md) - :material-delta: [Change Log](changelog.md) -- :material-offer: [Contributing](contributing.md) -- :material-arrow-decision: [Decision Records](../adr/index.md) - :material-copyright: [Copyright](copyright.md) - :material-inbox-arrow-down: [Contact Us](contact_us.md) diff --git a/docs/index.md b/docs/index.md index 3aa6fd88..3a5bd116 100644 --- a/docs/index.md +++ b/docs/index.md @@ -55,4 +55,7 @@ We have organized the SSVC documentation into four main sections: [:octicons-arrow-right-24: Reference](reference/index.md) -
\ No newline at end of file + + + +{% include-markdown "_includes/helping_out.md" heading-offset=1 %} \ No newline at end of file diff --git a/mkdocs.yml b/mkdocs.yml index 5f0e7994..b9bca039 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -78,14 +78,13 @@ nav: - Calculator: 'ssvc-calc/index.html' - About: - Intro: 'about/index.md' - - Change log: 'about/changelog.md' - - Contributing: 'about/contributing.md' + - Community Engagement: 'about/contributing.md' # - FAQ: 'about/faq.md' - Decision Records: 'adr/index.md' - Acknowledgements: 'about/acknowledgements.md' + - Change log: 'about/changelog.md' - Copyright: 'about/copyright.md' - Contact: 'about/contact_us.md' - - Issue Tracker: 'https://github.com/CERTCC/SSVC/issues' not_in_nav: | _*.md _*/**/*.md @@ -152,9 +151,18 @@ markdown_extensions: - tables extra: social: + - icon: material/message-question + link: https://github.com/CERTCC/SSVC/issues/new?template=question.md + name: Ask a Question - icon: fontawesome/solid/bug - link: https://github.com/CERTCC/SSVC/issues - name: Report an Issue or Suggest a Change + link: https://github.com/CERTCC/SSVC/issues/new?template=bug_report.md + name: Report a Problem + - icon: material/lightbulb-on + link: https://github.com/CERTCC/SSVC/issues/new?template=feature_request.md + name: Request a Feature + - icon: fontawesome/regular/comments + link: https://github.com/CERTCC/SSVC/discussions + name: SSVC Community Discussions - icon: fontawesome/brands/github link: https://github.com/CERTCC/SSVC name: CERTCC/SSVC on Github From da8f6cdc251a3cce39bf595a2097791bf55a2d8c Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Sat, 17 Feb 2024 00:10:09 -0500 Subject: [PATCH 081/113] Make link_checker.yml run automatically on push to main (#471) --- .github/workflows/link_checker.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.github/workflows/link_checker.yml b/.github/workflows/link_checker.yml index cbceedfb..6d0f83c7 100644 --- a/.github/workflows/link_checker.yml +++ b/.github/workflows/link_checker.yml @@ -1,5 +1,9 @@ name: Link Checker on: + push: + branches: + # run on any push to main + - main pull_request: paths: # run on any PR that modifies a markdown file From 66337969e5eed3f9846acd014ebb3f4550abe767 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 19 Feb 2024 11:35:21 -0500 Subject: [PATCH 082/113] Bump the mkdocs group with 1 update (#477) Bumps the mkdocs group with 1 update: [mkdocs-material](https://github.com/squidfunk/mkdocs-material). Updates `mkdocs-material` from 9.5.9 to 9.5.10 - [Release notes](https://github.com/squidfunk/mkdocs-material/releases) - [Changelog](https://github.com/squidfunk/mkdocs-material/blob/master/CHANGELOG) - [Commits](https://github.com/squidfunk/mkdocs-material/compare/9.5.9...9.5.10) --- updated-dependencies: - dependency-name: mkdocs-material dependency-type: direct:production update-type: version-update:semver-patch dependency-group: mkdocs ... Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 57f552a6..3895127f 100644 --- a/requirements.txt +++ b/requirements.txt @@ -2,7 +2,7 @@ mkdocs==1.5.3 mkdocs-bibtex==2.12.0 mkdocs-include-markdown-plugin==6.0.4 mkdocs-table-reader-plugin==2.1.0 -mkdocs-material==9.5.9 +mkdocs-material==9.5.10 mkdocs-material-extensions==1.3.1 mkdocstrings==0.24.0 mkdocstrings-python==1.8.0 From 6639fc5e37aa7831a4fc23d4660e7222e0dcea7c Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 19 Feb 2024 11:37:49 -0500 Subject: [PATCH 083/113] Bump scikit-learn from 1.4.0 to 1.4.1.post1 (#478) Bumps [scikit-learn](https://github.com/scikit-learn/scikit-learn) from 1.4.0 to 1.4.1.post1. - [Release notes](https://github.com/scikit-learn/scikit-learn/releases) - [Commits](https://github.com/scikit-learn/scikit-learn/compare/1.4.0...1.4.1.post1) --- updated-dependencies: - dependency-name: scikit-learn dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 3895127f..7d0478f9 100644 --- a/requirements.txt +++ b/requirements.txt @@ -10,6 +10,6 @@ mkdocs-print-site-plugin==2.3.6 dataclasses-json==0.6.4 thefuzz==0.22.1 pandas==2.2.0 -scikit-learn==1.4.0 +scikit-learn==1.4.1.post1 jsonschema==4.21.1 networkx==3.2.1 From 57df11eac08a09a5b4cb7556715cbca4761ba46b Mon Sep 17 00:00:00 2001 From: bkoo <111892109+sei-bkoo@users.noreply.github.com> Date: Mon, 19 Feb 2024 11:56:38 -0500 Subject: [PATCH 084/113] Human impact change proposal (#476) * Update human_impact.md updated human_impact.md * Update human_impact.md updated human_impact.md (v2) * revise intro sentence in human_impact.md --------- Co-authored-by: Allen D. Householder --- docs/reference/decision_points/human_impact.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/docs/reference/decision_points/human_impact.md b/docs/reference/decision_points/human_impact.md index e5eb7c95..a8a22036 100644 --- a/docs/reference/decision_points/human_impact.md +++ b/docs/reference/decision_points/human_impact.md @@ -7,18 +7,14 @@ *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. +Note: This is a compound decision point[^1], 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 -as a dimension reduction step as follows. +*Human Impact* is a combination of how a vulnerability can affect an organization's mission essential functions as well as +safety considerations, whether for the organization's personnel or the public at large. 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. Therefore we combine the two lesser mission impacts of degraded and MEF support crippled into a single category, while retaining the distinction between MEF Failure and Mission Failure at the extreme. This gives us three levels of mission impact to work with. - On the other hand, most organizations tend to have lower tolerance for variance in safety. Even small deviations in safety are unlikely to go unnoticed or unaddressed. We suspect that the presence of regulatory oversight for safety issues and its absence at the lower end of the mission impact scale influences this behavior. @@ -26,6 +22,13 @@ Because of this higher sensitivity to safety concerns, we chose to retain a four We then combine Mission Impact with Situated Safety impact and map them onto a 4-tiered scale (Low, Medium, High, Very High). The mapping is shown in the table above. +[^1]: 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 +as a dimension reduction step. + + ## Safety and Mission Impact Decision Points for Industry Sectors We expect to encounter diversity in both safety and mission impacts across different organizations. From 054789b8c05b6b2c3f786cf9ee01a7dc1035942d Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Tue, 20 Feb 2024 13:56:28 -0500 Subject: [PATCH 085/113] make safety table formats look better (#479) --- .../decision_points/safety_impact_2_0_0.json | 8 +-- .../decision_points/safety_impact_2_0_0.md | 8 +-- src/ssvc/decision_points/safety_impact.py | 60 +++++++++---------- 3 files changed, 38 insertions(+), 38 deletions(-) diff --git a/data/json/decision_points/safety_impact_2_0_0.json b/data/json/decision_points/safety_impact_2_0_0.json index f2e86410..795813bb 100644 --- a/data/json/decision_points/safety_impact_2_0_0.json +++ b/data/json/decision_points/safety_impact_2_0_0.json @@ -8,22 +8,22 @@ { "key": "N", "name": "Negligible", - "description": "Any one or more of these conditions hold. Physical harm: Minor injuries at worst (IEC 61508 Negligible). Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard. System resiliency: Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation. Environment: Minor externalities (property damage, environmental damage, etc.) imposed on other parties. Financial Financial losses, which are not readily absorbable, to multiple persons. Psychological: Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons." + "description": "Any one or more of these conditions hold.

- *Physical harm*: Minor injuries at worst (IEC 61508 Negligible).
- *Operator resiliency*: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard.
- *System resiliency*: Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation.
- *Environment*: Minor externalities (property damage, environmental damage, etc.) imposed on other parties.
- *Financial*: Financial losses, which are not readily absorbable, to multiple persons.
- *Psychological*: Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons." }, { "key": "M", "name": "Marginal", - "description": "Any one or more of these conditions hold. Physical harm: Major injuries to one or more persons (IEC 61508 Marginal). Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard. System resiliency: System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation. Environment: Major externalities (property damage, environmental damage, etc.) imposed on other parties. Financial: Financial losses that likely lead to bankruptcy of multiple persons. Psychological: Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people." + "description": "Any one or more of these conditions hold.

- *Physical harm*: Major injuries to one or more persons (IEC 61508 Marginal).
- *Operator resiliency*: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard.
- *System resiliency*: System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation.
- *Environment*: Major externalities (property damage, environmental damage, etc.) imposed on other parties.
- *Financial*: Financial losses that likely lead to bankruptcy of multiple persons.
- *Psychological*: Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people." }, { "key": "R", "name": "Critical", - "description": "Any one or more of these conditions hold. Physical harm: Loss of life (IEC 61508 Critical). Operator resiliency: Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly. System resiliency: Parts of the cyber-physical system break; system\u2019s ability to recover lost functionality remains intact. Environment: Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties. Financial: Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state. Psychological: N/A." + "description": "Any one or more of these conditions hold.

- *Physical harm*: Loss of life (IEC 61508 Critical).
- *Operator resiliency*: Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly.
- *System resiliency*: Parts of the cyber-physical system break; system\u2019s ability to recover lost functionality remains intact.
- *Environment*: Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties.
- *Financial*: Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state.
- *Psychological*: N/A." }, { "key": "C", "name": "Catastrophic", - "description": "Any one or more of these conditions hold. Physical harm: Multiple loss of life (IEC 61508 Catastrophic). Operator resiliency: Operator incapacitated (includes fatality or otherwise incapacitated). System resiliency: Total loss of whole cyber-physical system, of which the software is a part. Environment: Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties. Financial: Social systems (elections, financial grid, etc.) supported by the software collapse. Psychological: N/A." + "description": "Any one or more of these conditions hold.

- *Physical harm*: Multiple loss of life (IEC 61508 Catastrophic).
- *Operator resiliency*: Operator incapacitated (includes fatality or otherwise incapacitated).
- *System resiliency*: Total loss of whole cyber-physical system, of which the software is a part.
- *Environment*: Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties.
- *Financial*: Social systems (elections, financial grid, etc.) supported by the software collapse.
- *Psychological*: N/A." } ] } \ No newline at end of file diff --git a/docs/_generated/decision_points/safety_impact_2_0_0.md b/docs/_generated/decision_points/safety_impact_2_0_0.md index c8a2c2bf..a13fb828 100644 --- a/docs/_generated/decision_points/safety_impact_2_0_0.md +++ b/docs/_generated/decision_points/safety_impact_2_0_0.md @@ -7,10 +7,10 @@ | Value | Definition | |:-----|:-----------| - | Negligible | Any one or more of these conditions hold. Physical harm: Minor injuries at worst (IEC 61508 Negligible). Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard. System resiliency: Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation. Environment: Minor externalities (property damage, environmental damage, etc.) imposed on other parties. Financial Financial losses, which are not readily absorbable, to multiple persons. Psychological: Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons. | - | Marginal | Any one or more of these conditions hold. Physical harm: Major injuries to one or more persons (IEC 61508 Marginal). Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard. System resiliency: System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation. Environment: Major externalities (property damage, environmental damage, etc.) imposed on other parties. Financial: Financial losses that likely lead to bankruptcy of multiple persons. Psychological: Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people. | - | Critical | Any one or more of these conditions hold. Physical harm: Loss of life (IEC 61508 Critical). Operator resiliency: Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly. System resiliency: Parts of the cyber-physical system break; system’s ability to recover lost functionality remains intact. Environment: Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties. Financial: Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state. Psychological: N/A. | - | Catastrophic | Any one or more of these conditions hold. Physical harm: Multiple loss of life (IEC 61508 Catastrophic). Operator resiliency: Operator incapacitated (includes fatality or otherwise incapacitated). System resiliency: Total loss of whole cyber-physical system, of which the software is a part. Environment: Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties. Financial: Social systems (elections, financial grid, etc.) supported by the software collapse. Psychological: N/A. | + | Negligible | Any one or more of these conditions hold.

- *Physical harm*: Minor injuries at worst (IEC 61508 Negligible).
- *Operator resiliency*: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard.
- *System resiliency*: Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation.
- *Environment*: Minor externalities (property damage, environmental damage, etc.) imposed on other parties.
- *Financial*: Financial losses, which are not readily absorbable, to multiple persons.
- *Psychological*: Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons. | + | Marginal | Any one or more of these conditions hold.

- *Physical harm*: Major injuries to one or more persons (IEC 61508 Marginal).
- *Operator resiliency*: Requires action by system operator to maintain safe system state as a result of exploitation of the vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard.
- *System resiliency*: System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation.
- *Environment*: Major externalities (property damage, environmental damage, etc.) imposed on other parties.
- *Financial*: Financial losses that likely lead to bankruptcy of multiple persons.
- *Psychological*: Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people. | + | Critical | Any one or more of these conditions hold.

- *Physical harm*: Loss of life (IEC 61508 Critical).
- *Operator resiliency*: Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly.
- *System resiliency*: Parts of the cyber-physical system break; system’s ability to recover lost functionality remains intact.
- *Environment*: Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties.
- *Financial*: Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state.
- *Psychological*: N/A. | + | Catastrophic | Any one or more of these conditions hold.

- *Physical harm*: Multiple loss of life (IEC 61508 Catastrophic).
- *Operator resiliency*: Operator incapacitated (includes fatality or otherwise incapacitated).
- *System resiliency*: Total loss of whole cyber-physical system, of which the software is a part.
- *Environment*: Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties.
- *Financial*: Social systems (elections, financial grid, etc.) supported by the software collapse.
- *Psychological*: N/A. | === "JSON" diff --git a/src/ssvc/decision_points/safety_impact.py b/src/ssvc/decision_points/safety_impact.py index b33b3ca6..691263c2 100644 --- a/src/ssvc/decision_points/safety_impact.py +++ b/src/ssvc/decision_points/safety_impact.py @@ -81,51 +81,51 @@ CATASTROPHIC_2 = SsvcDecisionPointValue( name="Catastrophic", key="C", - description="Any one or more of these conditions hold. " - "Physical harm: Multiple loss of life (IEC 61508 Catastrophic). " - "Operator resiliency: Operator incapacitated (includes fatality or otherwise incapacitated). " - "System resiliency: Total loss of whole cyber-physical system, of which the software is a part. " - "Environment: Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties. " - "Financial: Social systems (elections, financial grid, etc.) supported by the software collapse. " - "Psychological: N/A.", + description="Any one or more of these conditions hold.

" + "- *Physical harm*: Multiple loss of life (IEC 61508 Catastrophic).
" + "- *Operator resiliency*: Operator incapacitated (includes fatality or otherwise incapacitated).
" + "- *System resiliency*: Total loss of whole cyber-physical system, of which the software is a part.
" + "- *Environment*: Extreme externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties.
" + "- *Financial*: Social systems (elections, financial grid, etc.) supported by the software collapse.
" + "- *Psychological*: N/A.", ) CRITICAL = SsvcDecisionPointValue( name="Critical", key="R", - description="Any one or more of these conditions hold. " - "Physical harm: Loss of life (IEC 61508 Critical). " - "Operator resiliency: Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly. " - "System resiliency: Parts of the cyber-physical system break; system’s ability to recover lost functionality remains intact. " - "Environment: Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties. " - "Financial: Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state. " - "Psychological: N/A.", + description="Any one or more of these conditions hold.

" + "- *Physical harm*: Loss of life (IEC 61508 Critical).
" + "- *Operator resiliency*: Actions that would keep the system in a safe state are beyond system operator capabilities, resulting in adverse conditions; OR great physical distress to system operators such that they cannot be expected to operate the system properly.
" + "- *System resiliency*: Parts of the cyber-physical system break; system’s ability to recover lost functionality remains intact.
" + "- *Environment*: Serious externalities (threat to life as well as property, widespread environmental damage, measurable public health risks, etc.) imposed on other parties.
" + "- *Financial*: Socio-technical system (elections, financial grid, etc.) of which the affected component is a part is actively destabilized and enters unsafe state.
" + "- *Psychological*: N/A.", ) MARGINAL = SsvcDecisionPointValue( name="Marginal", key="M", - description="Any one or more of these conditions hold. " - "Physical harm: Major injuries to one or more persons (IEC 61508 Marginal). " - "Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the " - "vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard. " - "System resiliency: System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation. " - "Environment: Major externalities (property damage, environmental damage, etc.) imposed on other parties. " - "Financial: Financial losses that likely lead to bankruptcy of multiple persons. " - "Psychological: Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people.", + description="Any one or more of these conditions hold.

" + "- *Physical harm*: Major injuries to one or more persons (IEC 61508 Marginal).
" + "- *Operator resiliency*: Requires action by system operator to maintain safe system state as a result of exploitation of the " + "vulnerability where operator actions would be within their capabilities but the actions require their full attention and effort; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard.
" + "- *System resiliency*: System safety margin effectively eliminated but no actual harm; OR failure of system functional capabilities that support safe operation.
" + "- *Environment*: Major externalities (property damage, environmental damage, etc.) imposed on other parties.
" + "- *Financial*: Financial losses that likely lead to bankruptcy of multiple persons.
" + "- *Psychological*: Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people.", ) NEGLIGIBLE = SsvcDecisionPointValue( name="Negligible", key="N", - description="Any one or more of these conditions hold. " - "Physical harm: Minor injuries at worst (IEC 61508 Negligible). " - "Operator resiliency: Requires action by system operator to maintain safe system state as a result of exploitation of the " - "vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard. " - "System resiliency: Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation. " - "Environment: Minor externalities (property damage, environmental damage, etc.) imposed on other parties. " - "Financial Financial losses, which are not readily absorbable, to multiple persons. " - "Psychological: Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons.", + description="Any one or more of these conditions hold.

" + "- *Physical harm*: Minor injuries at worst (IEC 61508 Negligible).
" + "- *Operator resiliency*: Requires action by system operator to maintain safe system state as a result of exploitation of the " + "vulnerability where operator actions would be well within expected operator abilities; OR causes a minor occupational safety hazard.
" + "- *System resiliency*: Small reduction in built-in system safety margins; OR small reduction in system functional capabilities that support safe operation.
" + "- *Environment*: Minor externalities (property damage, environmental damage, etc.) imposed on other parties.
" + "- *Financial*: Financial losses, which are not readily absorbable, to multiple persons.
" + "- *Psychological*: Emotional or psychological harm, sufficient to be cause for counselling or therapy, to multiple persons.", ) From eecfa08632e58cb22b471514bce0738a24ab19b4 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Tue, 20 Feb 2024 13:57:15 -0500 Subject: [PATCH 086/113] Add topo sort to csv analyzer and policy generator (#473) * fix ordering of decision point values * add topology checks * update generated examples --- .../report_credibility_1_0_0.json | 10 +- .../decision_points/report_public_1_0_0.json | 10 +- .../report_credibility_1_0_0.md | 2 +- .../decision_points/report_public_1_0_0.md | 2 +- src/ssvc/csv_analyzer.py | 117 ++++++++++++++++-- .../decision_points/report_credibility.py | 19 ++- src/ssvc/decision_points/report_public.py | 19 ++- src/ssvc/policy_generator.py | 53 +++++++- src/test/test_csv_analyzer.py | 9 +- src/test/test_policy_generator.py | 36 +++++- 10 files changed, 242 insertions(+), 35 deletions(-) diff --git a/data/json/decision_points/report_credibility_1_0_0.json b/data/json/decision_points/report_credibility_1_0_0.json index 68ce1143..0b1c910a 100644 --- a/data/json/decision_points/report_credibility_1_0_0.json +++ b/data/json/decision_points/report_credibility_1_0_0.json @@ -5,15 +5,15 @@ "name": "Report Credibility", "description": "Is the report credible?", "values": [ - { - "key": "C", - "name": "Credible", - "description": "The report is credible." - }, { "key": "NC", "name": "Not Credible", "description": "The report is not credible." + }, + { + "key": "C", + "name": "Credible", + "description": "The report is credible." } ] } \ No newline at end of file diff --git a/data/json/decision_points/report_public_1_0_0.json b/data/json/decision_points/report_public_1_0_0.json index 522473dd..195b8c33 100644 --- a/data/json/decision_points/report_public_1_0_0.json +++ b/data/json/decision_points/report_public_1_0_0.json @@ -5,15 +5,15 @@ "name": "Report Public", "description": "Is a viable report of the details of the vulnerability already publicly available?", "values": [ - { - "key": "N", - "name": "No", - "description": "No public report of the vulnerability exists." - }, { "key": "Y", "name": "Yes", "description": "A public report of the vulnerability exists." + }, + { + "key": "N", + "name": "No", + "description": "No public report of the vulnerability exists." } ] } \ No newline at end of file diff --git a/docs/_generated/decision_points/report_credibility_1_0_0.md b/docs/_generated/decision_points/report_credibility_1_0_0.md index 7494a7b1..0d1ed805 100644 --- a/docs/_generated/decision_points/report_credibility_1_0_0.md +++ b/docs/_generated/decision_points/report_credibility_1_0_0.md @@ -7,8 +7,8 @@ | Value | Definition | |:-----|:-----------| - | Credible | The report is credible. | | Not Credible | The report is not credible. | + | Credible | The report is credible. | === "JSON" diff --git a/docs/_generated/decision_points/report_public_1_0_0.md b/docs/_generated/decision_points/report_public_1_0_0.md index 80bee355..2f4a6c79 100644 --- a/docs/_generated/decision_points/report_public_1_0_0.md +++ b/docs/_generated/decision_points/report_public_1_0_0.md @@ -7,8 +7,8 @@ | Value | Definition | |:-----|:-----------| - | No | No public report of the vulnerability exists. | | Yes | A public report of the vulnerability exists. | + | No | No public report of the vulnerability exists. | === "JSON" diff --git a/src/ssvc/csv_analyzer.py b/src/ssvc/csv_analyzer.py index 81807f2d..c1c668af 100644 --- a/src/ssvc/csv_analyzer.py +++ b/src/ssvc/csv_analyzer.py @@ -40,7 +40,7 @@ Higher values imply more important features. """ -# Copyright (c) 2023 Carnegie Mellon University and Contributors. +# Copyright (c) 2023-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 @@ -54,14 +54,19 @@ # U.S. Patent and Trademark Office by Carnegie Mellon University import argparse +import logging import re import sys +from itertools import product +import networkx as nx import pandas as pd import sklearn.inspection from sklearn.base import clone from sklearn.tree import DecisionTreeClassifier +logger = logging.getLogger(__name__) + def _col_norm(c: str) -> str: """ @@ -203,12 +208,31 @@ def _parse_args(args) -> argparse.Namespace: def main(): + # set up root logger + logger = logging.getLogger() + logger.setLevel(logging.INFO) + hdlr = logging.StreamHandler() + logger.addHandler(hdlr) + args = _parse_args(sys.argv[1:]) csvfile = args.csvfile # read csv df = pd.read_csv(csvfile) + print("Checking for valid topological order...") + + problems = check_topological_order(df, args.outcol) + + if len(problems): + print("Not topologically sorted!") + + for problem in problems: + print( + f"Problem: {problem['u']} ({problem['u_outcome']}) is greater than {problem['v']} ({problem['v_outcome']})" + ) + sys.exit(1) + if args.permutation: imp = permute_feature_importance(df, args.outcol) print(f"Feature Permutation Importance for {df.columns}") @@ -219,7 +243,7 @@ def main(): print(imp) -def _create_dt_classifier( +def _prepare_data( df: pd.DataFrame, target: str, permute: bool = False ) -> (pd.DataFrame, pd.DataFrame): """ @@ -251,10 +275,8 @@ def _create_dt_classifier( mapper = {v: k for (k, v) in codes} X[newcol] = X[c].replace(mapper) X2 = X[cols] - # construct tree - dt = DecisionTreeClassifier(random_state=99, criterion="entropy") - return dt, X2, y + return X2, y def drop_col_feature_importance(df: pd.DataFrame, target: str) -> pd.DataFrame: @@ -268,7 +290,10 @@ def drop_col_feature_importance(df: pd.DataFrame, target: str) -> pd.DataFrame: Returns: a dataframe of feature importances """ - dt, X2, y = _create_dt_classifier(df, target) + X2, y = _prepare_data(df, target) + # construct tree + dt = DecisionTreeClassifier(random_state=99, criterion="entropy") + imp = _drop_col_feat_imp(dt, X2, y) return imp @@ -284,10 +309,88 @@ def permute_feature_importance(df: pd.DataFrame, target: str) -> pd.DataFrame: Returns: a dataframe of feature importances """ - dt, X2, y = _create_dt_classifier(df, target) + X2, y = _prepare_data(df, target) + # construct tree + dt = DecisionTreeClassifier(random_state=99, criterion="entropy") + imp = _perm_feat_imp(dt, X2, y) return imp +def check_topological_order(df, target): + # split df into features and target + X, y = _prepare_data(df, target) + + # convert outcome to numeric codes + codes = list(enumerate(y.unique())) + mapper = {v: k for (k, v) in codes} + y = y.replace(mapper) + + # create a graph of the nodes, assign the outcome value to each node + # and then check that the graph is topologically sorted + # (i.e. no edges point backwards) + G = nx.DiGraph() + # each row of X is a single node + for i, row in enumerate(X.iterrows()): + rownum, rowval = row + + # cast the row to a tuple so we can use it as a node + node = tuple(rowval) + G.add_node(node, outcome=y.iloc[i]) + + # add edges + for u, v in product(G.nodes, G.nodes): + # skip self edges + if u == v: + continue + + # u is less than v if all elements of u are less than or equal to v + if all(u[i] <= v[i] for i in range(len(u))): + # and at least one element of u is less than v + if any(u[i] < v[i] for i in range(len(u))): + # add edge if not already there + if not G.has_edge(u, v): + G.add_edge(u, v) + + # v is less than u if all elements of v are less than or equal to u + if all(v[i] <= u[i] for i in range(len(v))): + # and at least one element of v is less than u + if any(v[i] < u[i] for i in range(len(v))): + # add edge if not already there + if not G.has_edge(v, u): + G.add_edge(v, u) + + # take the transitive reduction of G to remove redundant edges + # this will remove all edges that are implied by other edges + # and leave only the minimal set of edges + # H is thus a Hasse diagram of G + H = nx.transitive_reduction(G) + + # networkx transitive reduction doesn't copy the node data + # so we need to copy it from G to H + for u in H.nodes: + H.nodes[u]["outcome"] = G.nodes[u]["outcome"] + + logger.debug(f"Original graph: {len(G.nodes)} nodes with {len(G.edges)} edges") + logger.debug(f"Reduced graph: {len(H.nodes)} nodes with {len(H.edges)} edges") + + problems = [] + # check if the outcome is topologically sorted + for u, v in H.edges: + if H.nodes[u]["outcome"] > H.nodes[v]["outcome"]: + problem = { + "u": u, + "v": v, + "u_outcome": H.nodes[u]["outcome"], + "v_outcome": H.nodes[v]["outcome"], + } + problems.append(problem) + + if len(problems) == 0: + logger.info("No topological problems found") + + return problems + + if __name__ == "__main__": main() diff --git a/src/ssvc/decision_points/report_credibility.py b/src/ssvc/decision_points/report_credibility.py index 38722be5..93ff6c4b 100644 --- a/src/ssvc/decision_points/report_credibility.py +++ b/src/ssvc/decision_points/report_credibility.py @@ -1,10 +1,21 @@ #!/usr/bin/env python """ -file: report_credibility -author: adh -created_at: 9/21/23 11:24 AM +Provides the SSVC Report Credibility Decision Point """ +# Copyright (c) 2023-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 NOT_CREDIBLE = SsvcDecisionPointValue( @@ -25,8 +36,8 @@ key="RC", version="1.0.0", values=( - CREDIBLE, NOT_CREDIBLE, + CREDIBLE, ), ) diff --git a/src/ssvc/decision_points/report_public.py b/src/ssvc/decision_points/report_public.py index 4141ae89..7947e1fb 100644 --- a/src/ssvc/decision_points/report_public.py +++ b/src/ssvc/decision_points/report_public.py @@ -1,9 +1,20 @@ #!/usr/bin/env python """ -file: report_public -author: adh -created_at: 9/21/23 11:15 AM +Provides the SSVC Report Public Decision Point """ +# Copyright (c) 2023-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 YES = SsvcDecisionPointValue( @@ -24,8 +35,8 @@ key="RP", version="1.0.0", values=( - NO, YES, + NO, ), ) diff --git a/src/ssvc/policy_generator.py b/src/ssvc/policy_generator.py index 8df4c0f3..9acce2c1 100644 --- a/src/ssvc/policy_generator.py +++ b/src/ssvc/policy_generator.py @@ -90,7 +90,6 @@ def __init__( raise ValueError(f"Outcome weights must sum to 1.0, but sum to {total}") self.outcome_weights = outcome_weights - logger.debug(f"Outcome weights: {self.outcome_weights}") self.policy: pd.DataFrame = None @@ -219,7 +218,7 @@ def _assign_outcomes(self): # if we've assigned enough of this outcome, move on to the next outcome if ( - outcome_idx < (len(self.outcomes.outcomes)) + outcome_idx < (len(outcomes) - 1) and outcome_counts[outcome_idx] <= assigned_counts[outcome_idx] ): outcome_idx += 1 @@ -277,6 +276,56 @@ def _enumerate_dp_values(self): self._enumerated_vec = vec + def _confirm_topological_order(self, node_order: list) -> None: + """ + Throw an exception if the given node order is not a valid topological sort of the graph. + + Args: + node_order: a list of nodes expected to be in topological order + + Returns: + None: if the node order is a valid topological sort of the graph + + Raises: + ValueError: If the node order is not a valid topological sort of the graph + """ + # all nodes must be in the graph + for node in node_order: + if node not in self.G.nodes: + raise ValueError(f"Node order contains node {node} not in the graph") + + for node in self.G.nodes: + if node not in node_order: + raise ValueError(f"Graph contains node {node} not in the node order") + + node_idx = {node: i for i, node in enumerate(node_order)} + + for u, v in self.G.edges: + if node_idx[u] > node_idx[v]: + raise ValueError( + f"Node order is not a valid topological sort of the graph ({u} > {v} are out of order)" + ) + + def _is_topological_order(self, node_order: list) -> bool: + """ + Determine whether the given node order is a valid topological sort of the graph. + This is the boolean version of _confirm_topological_order. + + Args: + node_order: a list of nodes expected to be in topological order + + Returns: + True: if the node order is a valid topological sort of the graph + False: if the node order is not a valid topological sort of the graph + """ + try: + self._confirm_topological_order(node_order) + except ValueError as e: + logger.warning(e) + return False + + return True + def main(): from ssvc.decision_points.automatable import AUTOMATABLE_1 diff --git a/src/test/test_csv_analyzer.py b/src/test/test_csv_analyzer.py index 7210132a..b010367a 100644 --- a/src/test/test_csv_analyzer.py +++ b/src/test/test_csv_analyzer.py @@ -1,4 +1,4 @@ -# Copyright (c) 2023 Carnegie Mellon University and Contributors. +# Copyright (c) 2023-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 @@ -149,21 +149,20 @@ def test_parse_args(self): self.assertEqual(args.outcol, "priority") self.assertFalse(args.permutation) - def test_create_dt_classifier(self): + def test_prepare_data(self): df = pd.DataFrame() target = "outcome" # key error when target is not in df.columns self.assertNotIn(target, df.columns) - self.assertRaises(KeyError, acsv._create_dt_classifier, df, target) + self.assertRaises(KeyError, acsv._prepare_data, df, target) df["color"] = [1, 1, 1, 1, 2, 2, 2, 2] df["size"] = [1, 2, 3, 4, 1, 2, 3, 4] df["outcome"] = [1, 1, 1, 1, 2, 2, 2, 2] # create_dt_classifier should return a DecisionTreeClassifier object - model, x, y = acsv._create_dt_classifier(df, target) - self.assertIsInstance(model, acsv.DecisionTreeClassifier) + x, y = acsv._prepare_data(df, target) self.assertIsInstance(x, pd.DataFrame) self.assertIsInstance(y, pd.Series) diff --git a/src/test/test_policy_generator.py b/src/test/test_policy_generator.py index a396f5aa..bce92cf4 100644 --- a/src/test/test_policy_generator.py +++ b/src/test/test_policy_generator.py @@ -1,4 +1,4 @@ -# Copyright (c) 2023 Carnegie Mellon University and Contributors. +# Copyright (c) 2023-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 @@ -286,6 +286,40 @@ def test_validate_paths(self): with self.assertRaises(ValueError): pg._validate_paths() + def test_is_topological_order(self): + pg = PolicyGenerator( + dp_group=self.dpg, + outcomes=self.og, + ) + # just replace the graph with one we make up here + # 0 - 1 - 2 - 4 - 5 + # \- 3 -/ + + pg.G = nx.DiGraph() + pg.G.add_edges_from([(0, 1), (1, 2), (1, 3), (2, 4), (3, 4), (4, 5)]) + + self.assertTrue(pg._is_topological_order([0, 1, 2, 3, 4, 5])) + self.assertTrue(pg._is_topological_order([0, 1, 3, 2, 4, 5])) + self.assertFalse(pg._is_topological_order([0, 1, 2, 4, 3, 5])) + self.assertFalse(pg._is_topological_order([0, 1, 2, 3, 5])) + + def test_confirm_topological_order(self): + pg = PolicyGenerator( + dp_group=self.dpg, + outcomes=self.og, + ) + # just replace the graph with one we make up here + # 0 - 1 - 2 - 4 - 5 + # \- 3 -/ + + pg.G = nx.DiGraph() + pg.G.add_edges_from([(0, 1), (1, 2), (1, 3), (2, 4), (3, 4), (4, 5)]) + + self.assertIsNone(pg._confirm_topological_order([0, 1, 2, 3, 4, 5])) + self.assertIsNone(pg._confirm_topological_order([0, 1, 3, 2, 4, 5])) + self.assertRaises(ValueError, pg._confirm_topological_order, [0, 1, 2, 4, 3, 5]) + self.assertRaises(ValueError, pg._confirm_topological_order, [0, 1, 2, 3, 5]) + if __name__ == "__main__": unittest.main() From cac6e34a542a9fcda496bebc1e889c39ed82d507 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Tue, 20 Feb 2024 19:37:30 -0500 Subject: [PATCH 087/113] reorder howto section nav (#484) --- docs/howto/index.md | 2 +- mkdocs.yml | 14 +++++++------- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/howto/index.md b/docs/howto/index.md index a9ed4093..53007ae8 100644 --- a/docs/howto/index.md +++ b/docs/howto/index.md @@ -48,10 +48,10 @@ fit your organization's needs.
+- :material-stairs: [Bootstrapping SSVC](bootstrap/index.md) - :material-factory: [Supplier Decision Model](supplier_tree.md) - :material-server-network: [Deployer Decision Model](deployer_tree.md) - :material-steering: [Coordinator Decision Models](coordination_intro.md) -- :material-stairs: [Bootstrapping SSVC](bootstrap/index.md) - :material-hand-saw: [Customizing SSVC](tree_customization.md) - :material-slope-uphill: [Acuity Ramp](acuity_ramp.md) diff --git a/mkdocs.yml b/mkdocs.yml index b9bca039..e217cfe1 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -30,7 +30,13 @@ nav: - Limitations: 'topics/limitations.md' - Future Work: 'topics/future_work.md' - SSVC How-To: - - Intro: 'howto/index.md' + - Overview: 'howto/index.md' + - Bootstrapping SSVC: + - Intro: 'howto/bootstrap/index.md' + - Prepare: 'howto/bootstrap/prepare.md' + - Collect: 'howto/bootstrap/collect.md' + - Use & Respond: 'howto/bootstrap/use.md' + - Summary: 'howto/bootstrap/summary.md' - Stakeholder Decision Models: - Supplier Decision Model: 'howto/supplier_tree.md' - Deployer Decision Model: 'howto/deployer_tree.md' @@ -38,12 +44,6 @@ nav: - About Coordination: 'howto/coordination_intro.md' - Coordination Decision: 'howto/coordination_decisions.md' - Publication Decision: 'howto/publication_decision.md' - - Bootstrapping SSVC: - - Intro: 'howto/bootstrap/index.md' - - Prepare: 'howto/bootstrap/prepare.md' - - Collect: 'howto/bootstrap/collect.md' - - Use & Respond: 'howto/bootstrap/use.md' - - Summary: 'howto/bootstrap/summary.md' - Customizing SSVC: 'howto/tree_customization.md' - Acuity Ramp: 'howto/acuity_ramp.md' - Reference: From 8b83b63aadcbe74183bacd3ed346cb7bb3d6580a Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 23 Feb 2024 15:32:22 -0500 Subject: [PATCH 088/113] Consolidate stakeholder specific decision model content into individual howto pages (#485) * break up enumerating_actions.md * break up units_of_work.md * revise supplier_tree.md and deployer_tree.md * revise coordination models * fix order of public value added decision point * resolves #316 * link fixes * s/policy choices/policy constraints/ in publication_decision.md * copy edit --- .../public_value_added_1_0_0.json | 12 +- .../public_value_added_1_0_0.md | 4 +- docs/_includes/_tree_notation_tip.md | 11 ++ docs/howto/bootstrap/prepare.md | 4 +- docs/howto/coordination_decisions.md | 47 ----- docs/howto/coordination_intro.md | 28 ++- docs/howto/coordination_triage_decision.md | 113 ++++++++++++ docs/howto/deployer_tree.md | 136 +++++++++++++- docs/howto/publication_decision.md | 168 ++++++++++++++---- docs/howto/supplier_tree.md | 100 ++++++++++- docs/howto/tree_customization.md | 4 +- docs/topics/enumerating_actions.md | 91 ---------- docs/topics/enumerating_decisions.md | 121 ++++++++++++- docs/topics/units_of_work.md | 99 ----------- mkdocs.yml | 4 +- .../decision_points/public_value_added.py | 24 ++- 16 files changed, 655 insertions(+), 311 deletions(-) create mode 100644 docs/_includes/_tree_notation_tip.md delete mode 100644 docs/howto/coordination_decisions.md create mode 100644 docs/howto/coordination_triage_decision.md delete mode 100644 docs/topics/enumerating_actions.md delete mode 100644 docs/topics/units_of_work.md 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__": From 5c1c1eebd3e491105e17ffec528c4b4451fedbd1 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 23 Feb 2024 15:34:42 -0500 Subject: [PATCH 089/113] Add _Establish Governance_ to _Prepare_ step of bootstrap process description (#488) * draft of governance step in prepare.md * add governance bit to prepare row of _steps_table.md * fix #487 * add headings, example blocks * add governance process to diagram * revise data mapping heading * refine diagram * fix heading levels * add CERT RMM sidebar --- docs/howto/bootstrap/_steps_table.md | 12 +-- docs/howto/bootstrap/prepare.md | 125 ++++++++++++++++++++++++- docs/howto/bootstrap/summary.md | 25 ++++- docs/howto/bootstrap/use.md | 135 +++++++++++---------------- 4 files changed, 209 insertions(+), 88 deletions(-) diff --git a/docs/howto/bootstrap/_steps_table.md b/docs/howto/bootstrap/_steps_table.md index 6182ac67..01c6e98e 100644 --- a/docs/howto/bootstrap/_steps_table.md +++ b/docs/howto/bootstrap/_steps_table.md @@ -1,6 +1,6 @@ -| Step | Description | -| ---- |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| [**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 according to the prioritization. | +| Step | Description | +| ---- |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| [**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, the data you need to inform the decision points, and the process for maintaining your decision model. | +| [**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 according to the prioritization. | diff --git a/docs/howto/bootstrap/prepare.md b/docs/howto/bootstrap/prepare.md index 7dc1f6c5..6a26200b 100644 --- a/docs/howto/bootstrap/prepare.md +++ b/docs/howto/bootstrap/prepare.md @@ -6,9 +6,13 @@ the information you need to make that decision, and the policy you want to use t Here is a diagram of the preparation process: ```mermaid +--- +title: Prepare to Use SSVC Overview +--- flowchart subgraph prep [Prepare to use SSVC] dcd{{Choose Decision to Model}} + governance[Establish Governance] outcomes[Define Outcomes] decisionpoints[Define Inputs] dataeng[Data Mapping] @@ -17,6 +21,8 @@ flowchart p[/Policy/] end dcd --> outcomes + dcd --> governance + governance --> governance outcomes --> decisionpoints dcd --> decisionpoints decisionpoints --> dataeng @@ -48,6 +54,9 @@ You can use one of these decisions, or you can define your own decision.
```mermaid +--- +title: Choose a Decision Process +--- flowchart LR subgraph dd[Choose Decision] dcd{{Choose Decision to Model}} @@ -73,6 +82,9 @@ We call the set of possible outcomes for a decision an outcome set. We have provided a number of example outcome sets in the SSVC documentation, but you can define your own outcome set to meet your needs. ```mermaid +--- +title: Outcomes Definition Process +--- flowchart LR subgraph dd[Choose Decision] d[/Decision/] @@ -116,6 +128,9 @@ Whether you choose from the existing decision points or define your own, the set decision is called a Decision Point Set. ```mermaid +--- +title: Inputs Definition Process +--- flowchart LR subgraph dd[Choose Decision] d[/Decision/] @@ -162,6 +177,9 @@ In fact, we find that it is often useful to represent policies in tabular form, 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 +--- +title: Policy Definition Process +--- flowchart LR subgraph do[Define Outcomes] oc[/Outcome Set/] @@ -190,13 +208,16 @@ flowchart LR 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. -## Data Mapping +## Map Data to Model Inputs In SSVC, data mapping is the process of defining what data can be used to assign a value to each decision point. The resulting data map indicates which data sources are relevant to each decision point, and how to interpret the data from each data source to assign a value to the decision point. ```mermaid +--- +title: Data Mapping Process +--- flowchart LR subgraph di[Define Inputs] dps[/Decision Point Set/] @@ -232,3 +253,105 @@ flowchart LR They define a data map that indicates that the data source for the _Service Level_ decision point is the file containing the SLA data, and document that the script they wrote will assign a value to the _Service Level_ decision point based on the SLA data. + + +!!! tip inline end "CERT RMM on Vulnerability Analysis and Resolution" + + The process of maintaining SSVC decision models is a governance process. + Ideally, it should be part of a larger governance process for vulnerability analysis and response. + The _CERT Resilience Management Model, Version 1.2_ + [Vulnerability Analysis and Resolution](https://insights.sei.cmu.edu/library/vulnerability-analysis-and-resolution-var-cert-rmm-process-area/) + ([VAR](https://insights.sei.cmu.edu/library/vulnerability-analysis-and-resolution-var-cert-rmm-process-area/)) chapter + covers a number of SSVC-related ideas: + + - _VAR:SG2 Identify and Analyze Vulnerabilities_ covers data mapping, vulnerability prioritization, + and identifying vulnerable assets + - _VAR:SG3 Manage Exposure to Vulnerabilities_ addresses strategies for vulnerability management + - _VAR:GG2 Institutionalize a Managed Process_ provides considerable detail on establishing a governance process for + vulnerability analysis and resolution. + + The entire CERT RMM collection can be found in the [SEI Digital Library](https://insights.sei.cmu.edu/library/cert-resilience-management-model-cert-rmm-collection/) + +## Establish Governance + +The final step in preparing to use SSVC is to establish a governance process for the decision model. +This process should ensure that the decision model remains relevant to the organization's needs and that the data +used to make decisions is accurate and up-to-date. +It need not be complex or burdensome. + +A lightweight governance process might resemble a review of this _Prepare_ step for each decision modeled using +SSVC. Each of the items we discussed above could be reviewed in turn, ensuring that: + +- The decision itself remains relevant to the organization +- The outcomes remain relevant to the decision +- The decision points remain relevant to the decision +- The policy remains relevant to the organization's needs +- The data sources remain relevant to informing the decision points + +Depending on the review, any necessary adjustments can be made to the outcomes, decision points, policy, data map, +or operational processes. + +```mermaid +--- +title: Governance Process for SSVC Use +--- +flowchart LR + +subgraph Governance + direction LR + ro[/Modify Outcomes?\] + mdp[/Modify Decision Points?\] + rp[/Modify Policy?\] + rds[/Modify Data Mapping?\] + oc[/Outcomes/] + dp[/Decision Points/] + dm[/Data Map/] + um{{Update Policy}} + po[/Policy/] +end + +ro -->|yes| oc +oc --> um +ro -->|no| mdp +mdp -->|yes| dp +dp --> um +mdp -->|no| rp +rp -->|yes| um +rp -->|no| rds +rds -->|yes| dm +um --> po +``` + +!!! example "A Simple Governance Process asks Questions" + + A simple governance process might include regular reviews of the decision model intended to answer the following + questions, starting with the decision itself: + + - Did we model the right decision(s)? + + - Are there new decisions we need to model? + - Do we need to maintain the existing decision models? + + If a new decision is to be modeled, the process would start over with the entire *Prepare* step. + + Then, for each decision model already in use: + + - Are the outcomes still relevant? + - Are the decision points in the model still relevant? + + - Are there decision points that are not as useful as we thought they would be? + - Are there new decision points we should add? + + - Does the policy still reflect our understanding and expectations of how we want to make this decision? + + - Have there been instances where the policy has led to a decision that we later regretted? + - Are there new constraints or requirements that the policy mapping does not capture? + + - Do we have the right data to inform the decision points in the decision model? + + - Are there new data sources we should consider? + - Are there data sources we are using that are no longer relevant? + - Is our data mapping still appropriate? + + + diff --git a/docs/howto/bootstrap/summary.md b/docs/howto/bootstrap/summary.md index 0f1f2f21..409c7fe6 100644 --- a/docs/howto/bootstrap/summary.md +++ b/docs/howto/bootstrap/summary.md @@ -10,11 +10,12 @@ The diagram below shows the complete process of using SSVC. ```mermaid -flowchart +flowchart TD start([Start]) subgraph prep [Prepare to use SSVC] dcd{{Choose Decision to Model}} d[/Decision/] + l4((1)) subgraph outcomes [Define Outcomes] oc1[/Use available
outcome sets?\] dos{{Define Outcome Sets}} @@ -22,6 +23,7 @@ subgraph prep [Prepare to use SSVC] cos{{Choose Outcome Set}} os[/Outcome Set/] end + l5((1)) subgraph decisionpoints [Define Inputs] dp1[/Use available
decision points?\] ddp{{Define Decision Points}} @@ -29,6 +31,7 @@ subgraph prep [Prepare to use SSVC] cdp{{Choose Decision Points}} dps[/Decision Point Set/] end + l6((1)) subgraph dataeng [Data Mapping] dd1[/Use existing data?\] dpm[/Data Map/] @@ -36,10 +39,17 @@ subgraph prep [Prepare to use SSVC] dd{{Define Data}} ddf[/Data Definition/] end + l7((1)) subgraph policy [Policy Development] dfp{{Define Policy}} p[/Policy/] end + subgraph gov [Governance] + eg{{Establish Governance Process}} + gp[[Governance Process]] + end + l3((1)) + end subgraph dataops [Data Operations] cd[Collect Data] @@ -56,7 +66,13 @@ subgraph runtime [Use SSVC] end r[Vulnerability Response] start --> dcd +start --> eg +eg --> gp +gp -->|ongoing| gp +gp --> l3 + dcd --> d +l4 --> oc1 d --> oc1 dps --> dd1 oc1 -->|y| oss @@ -71,8 +87,10 @@ dpt --> cdp cdp --> dps cos --> os oss --> cos +l7 --> dfp os --> dfp os --> dp1 +l5 --> dp1 d --> dp1 dps --> dp2d dp2d --> dpm @@ -93,7 +111,8 @@ p --> ap dp --> ap ap --> oc oc --> r -r --> l1((1)) -l2((1)) --> cd +r --> l1((2)) +l2((2)) --> cd +l6 --> dd1 ``` diff --git a/docs/howto/bootstrap/use.md b/docs/howto/bootstrap/use.md index fc1de0e2..282eab86 100644 --- a/docs/howto/bootstrap/use.md +++ b/docs/howto/bootstrap/use.md @@ -87,82 +87,42 @@ flowchart LR 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. +[Suppliers](../supplier_tree.md) and [deployers](../deployer_tree.md) 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. +[Coordinators](../coordination_intro.md) 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. +Any stakeholder making a decision on allocating effort should have a decision tree model its decision points and possible outcome 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. +### JSON Format -#### Abbreviated Format +We provide a structured communication format for SSVC information using JSON schemas. +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. -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. +- The [provision schema](https://github.com/CERTCC/SSVC/blob/main/data/schema/SSVC_Provision.schema.json) is equivalent to a decision model 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. -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. +!!! info "Deriving a Decision Point JSON key-value pair" -#### Full JSON format + 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: -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. + - 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. -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). -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 @@ -174,22 +134,33 @@ 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. +!!! example "Communicating All Possible States" + + 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). + + {% include-markdown "../../_generated/decision_points/utility.md" %} + + 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*](../../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`. + +!!! example "When Some Values Are Known (But Others Are Not)" + + 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). + + {% include-markdown "../../_generated/decision_points/value_density.md" %} + + {% include-markdown "../../_generated/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). + 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 +## 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. @@ -198,16 +169,20 @@ Some, such as [Utility](../../reference/decision_points/utility.md), are mostly 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. +!!! tip inline end "Focus on Automation" + + 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. + 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. +That is, the organization should re-evaluate 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. +### Decision Points Not Under Direct Control 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. @@ -223,12 +198,16 @@ Risk tolerance and risk appetite are primarily reflected in the priority labels | [*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. +### Decision Points Under Direct Control + +The following decision points are usually in the control of the organization running SSVC and should be re-evaluated 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) +### Timestamping SSVC Information + 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. From 2c84da018bf40062b34185bf26c64b7ee613ac4e Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 23 Feb 2024 15:35:14 -0500 Subject: [PATCH 090/113] add link to github tips wiki page (#491) --- docs/_includes/helping_out.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/_includes/helping_out.md b/docs/_includes/helping_out.md index e8885c48..e869620b 100644 --- a/docs/_includes/helping_out.md +++ b/docs/_includes/helping_out.md @@ -55,3 +55,9 @@ We welcome your feedback and contributions to SSVC. Here are some ways you can g !!! tip "Footer Icons" The icons in the footer of each page also provide links to engage with the SSVC community. + +!!! tip "Github Tips for New Contributors" + + If you are new to contributing to open source projects on Github, we've assembled some pointers + to help you get started in the [Github Tips for SSVC contributors](https://github.com/CERTCC/SSVC/wiki/Github-Tips-for-SSVC-contributors) + From 5915548b5f7324a1f0c3ce7dd2efec062a5883f5 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 23 Feb 2024 15:39:19 -0500 Subject: [PATCH 091/113] Reorder HowTo and Understanding in site nav (#490) * reorder nav to put HowTo before Understanding * add/revise prerequisite inset to point to other sections --- docs/howto/index.md | 38 +++++++++++++++++++++++++++----------- docs/index.md | 16 ++++++++-------- docs/topics/index.md | 12 ++++++++++++ mkdocs.yml | 34 +++++++++++++++++----------------- 4 files changed, 64 insertions(+), 36 deletions(-) diff --git a/docs/howto/index.md b/docs/howto/index.md index 53007ae8..91271235 100644 --- a/docs/howto/index.md +++ b/docs/howto/index.md @@ -7,8 +7,8 @@ - An interest in using SSVC in a vulnerability management process - Basic familiarity with SSVC - If you are unfamiliar with SSVC, we suggest you start with the - [Understanding SSVC](../topics/index.md) section, which provides necessary background detail. + If you are unfamiliar with SSVC, we suggest you start with the [Learning SSVC](../tutorials/index.md) section. + [Understanding SSVC](../topics/index.md) provides necessary background detail. For technical reference, see [Reference](../reference/index.md). -Given a specific [stakeholder](../topics/enumerating_stakeholders.md) [decision](../topics/enumerating_decisions.md) -and set of useful [decision points](../reference/decision_points/index.md), -we are now in a position to combine them into a -comprehensive set of decisions about the priority with which to act. +SSVC is a methodology for prioritizing vulnerability response based on the needs of various stakeholders. +At its core are the concepts of: + +- [**Stakeholder Roles**](../topics/enumerating_stakeholders.md): Different participants in the vulnerability response process have different needs and priorities. + Roles can include patch suppliers, deployers, coordinators, and others. +- [**Decisions**](../topics/enumerating_decisions.md): Each stakeholder role has a set of decisions to make about how to respond to vulnerabilities. + For a supplier, the decision might be about how to prioritize the creation of patches. For a deployer, the + decision might be about how to prioritize the deployment of patches. Coordinators usually need to decide whether + to coordinate a response, and whether to publish information about a vulnerability they've coordinated. +- [**Decision Points**](../reference/decision_points/index.md): Each decision is made based on a set of inputs, or decision points. These are the factors + that influence the decision. For example, a decision about whether to deploy a patch might be influenced by the + severity of the vulnerability, the availability of an exploit, and the impact of the vulnerability on the system. +- [**Outcomes**](../topics/enumerating_decisions.md): Each decision has a set of possible outcomes. These are the possible results of the decision. + For example, a decision about whether to deploy a patch might have outcomes like "immediate", "scheduled", "deferred", + and "out-of-cycle". + +Given these concepts, we can combine them into decision models to help stakeholders make 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 *Public PoC*) AND - - ([*System Exposure*](../reference/decision_points/system_exposure.md) IS *controlled*) AND - - ([*Automatable*](../reference/decision_points/automatable.md) IS *no*) AND - - ([*Human Impact*](../reference/decision_points/human_impact.md) IS *medium*) + + - ([*Exploitation*](../reference/decision_points/exploitation.md) IS *Public PoC*) AND + - ([*System Exposure*](../reference/decision_points/system_exposure.md) IS *controlled*) AND + - ([*Automatable*](../reference/decision_points/automatable.md) IS *no*) AND + - ([*Human Impact*](../reference/decision_points/human_impact.md) IS *medium*) + - 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). @@ -43,7 +59,7 @@ This example logical statement is captured in [line 35 of the deployer `.csv` fi There are different formats for capturing these prioritization decisions depending on how and where they are going to be used. In this documentation, 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 various stakeholders, followed by guidance on how to adapt and customize SSVC to +This section presents example decision models for various stakeholders, followed by guidance on how to adapt and customize SSVC to fit your organization's needs.
diff --git a/docs/index.md b/docs/index.md index 3a5bd116..686dbd3a 100644 --- a/docs/index.md +++ b/docs/index.md @@ -28,23 +28,23 @@ We have organized the SSVC documentation into four main sections: [:octicons-arrow-right-24: Learning SSVC](tutorials/index.md) -- :fontawesome-solid-book:{ .lg .middle } __Learn More about SSVC__ +- :material-clipboard-check:{ .lg .middle } __SSVC How To__ --- - 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. + 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: Understanding SSVC](topics/index.md) + [:octicons-arrow-right-24: SSVC How To](howto/index.md) -- :material-clipboard-check:{ .lg .middle } __SSVC How To__ +- :fontawesome-solid-book:{ .lg .middle } __Learn More about SSVC__ --- - 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. + 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: SSVC How To](howto/index.md) + [:octicons-arrow-right-24: Understanding SSVC](topics/index.md) - :material-book-open-page-variant:{ .lg .middle } __SSVC Reference__ diff --git a/docs/topics/index.md b/docs/topics/index.md index db7b8655..eff8e9f3 100644 --- a/docs/topics/index.md +++ b/docs/topics/index.md @@ -1,5 +1,17 @@ # Introduction +!!! tip inline end "Prerequisites" + + The [Understanding SSVC](index.md) section assumes that you have + + - Basic familiarity with SSVC + - An interest in learning more about the details of SSVC + + If you are unfamiliar with SSVC, we suggest you start with the [Learning SSVC](../tutorials/index.md) section. + [SSVC How-To](../howto/index.md) provides practical guidance for implementing SSVC in your organization. + For technical reference, see [Reference](../reference/index.md). + + This documentation defines a testable Stakeholder-Specific Vulnerability Categorization (SSVC) for prioritizing actions during vulnerability management. The stakeholders in vulnerability management are diverse. This diversity must be accommodated in the main functionality, rather than squeezed into hard-to-use optional features. diff --git a/mkdocs.yml b/mkdocs.yml index efffdafe..a8648e72 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -5,6 +5,23 @@ nav: - Learning SSVC: - Intro: 'tutorials/index.md' - SSVC Calculator: 'ssvc-calc/index.html' + - SSVC How-To: + - Overview: 'howto/index.md' + - Getting Started with SSVC: + - Intro: 'howto/bootstrap/index.md' + - Prepare: 'howto/bootstrap/prepare.md' + - Collect: 'howto/bootstrap/collect.md' + - Use & Respond: 'howto/bootstrap/use.md' + - Summary: 'howto/bootstrap/summary.md' + - Stakeholder Decision Models: + - Supplier Decision Model: 'howto/supplier_tree.md' + - Deployer Decision Model: 'howto/deployer_tree.md' + - Coordinator Decision Models: + - About Coordination: 'howto/coordination_intro.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' - Understanding SSVC: - Intro: 'topics/index.md' - State of Practice: 'topics/state_of_practice.md' @@ -27,23 +44,6 @@ nav: - Information Sources: 'topics/information_sources.md' - Limitations: 'topics/limitations.md' - Future Work: 'topics/future_work.md' - - SSVC How-To: - - Overview: 'howto/index.md' - - Bootstrapping SSVC: - - Intro: 'howto/bootstrap/index.md' - - Prepare: 'howto/bootstrap/prepare.md' - - Collect: 'howto/bootstrap/collect.md' - - Use & Respond: 'howto/bootstrap/use.md' - - Summary: 'howto/bootstrap/summary.md' - - Stakeholder Decision Models: - - Supplier Decision Model: 'howto/supplier_tree.md' - - Deployer Decision Model: 'howto/deployer_tree.md' - - Coordinator Decision Models: - - About Coordination: 'howto/coordination_intro.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' - Reference: - Intro: 'reference/index.md' - Decision Points: From 518c4b79bde3f9f9ef1a53594ee707f3d19b8a19 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 26 Feb 2024 11:16:48 -0500 Subject: [PATCH 092/113] Bump the mkdocs group with 1 update (#498) Bumps the mkdocs group with 1 update: [mkdocs-material](https://github.com/squidfunk/mkdocs-material). Updates `mkdocs-material` from 9.5.10 to 9.5.11 - [Release notes](https://github.com/squidfunk/mkdocs-material/releases) - [Changelog](https://github.com/squidfunk/mkdocs-material/blob/master/CHANGELOG) - [Commits](https://github.com/squidfunk/mkdocs-material/compare/9.5.10...9.5.11) --- updated-dependencies: - dependency-name: mkdocs-material dependency-type: direct:production update-type: version-update:semver-patch dependency-group: mkdocs ... Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 7d0478f9..84ee6691 100644 --- a/requirements.txt +++ b/requirements.txt @@ -2,7 +2,7 @@ mkdocs==1.5.3 mkdocs-bibtex==2.12.0 mkdocs-include-markdown-plugin==6.0.4 mkdocs-table-reader-plugin==2.1.0 -mkdocs-material==9.5.10 +mkdocs-material==9.5.11 mkdocs-material-extensions==1.3.1 mkdocstrings==0.24.0 mkdocstrings-python==1.8.0 From 48961a05a750755abe87dc113158247357f3b957 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 26 Feb 2024 11:18:16 -0500 Subject: [PATCH 093/113] Bump pandas from 2.2.0 to 2.2.1 (#499) Bumps [pandas](https://github.com/pandas-dev/pandas) from 2.2.0 to 2.2.1. - [Release notes](https://github.com/pandas-dev/pandas/releases) - [Commits](https://github.com/pandas-dev/pandas/compare/v2.2.0...v2.2.1) --- updated-dependencies: - dependency-name: pandas dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index 84ee6691..31c6f3de 100644 --- a/requirements.txt +++ b/requirements.txt @@ -9,7 +9,7 @@ mkdocstrings-python==1.8.0 mkdocs-print-site-plugin==2.3.6 dataclasses-json==0.6.4 thefuzz==0.22.1 -pandas==2.2.0 +pandas==2.2.1 scikit-learn==1.4.1.post1 jsonschema==4.21.1 networkx==3.2.1 From 5ce8321453e80b64c4dc3a3e570ca4fc5d4ac4b8 Mon Sep 17 00:00:00 2001 From: j--- Date: Tue, 27 Feb 2024 14:57:17 -0500 Subject: [PATCH 094/113] add initial draft of ADR (#492) * add initial draft of ADR * Update index.md make link text consistent with other ADRs * add ADR file * typographical changes * typographical changes --------- Co-authored-by: Allen D. Householder --- ...utomatable-and-value-density-and-CVSSv4.md | 50 +++++++++++++++++++ docs/adr/index.md | 1 + 2 files changed, 51 insertions(+) create mode 100644 docs/adr/0011-automatable-and-value-density-and-CVSSv4.md diff --git a/docs/adr/0011-automatable-and-value-density-and-CVSSv4.md b/docs/adr/0011-automatable-and-value-density-and-CVSSv4.md new file mode 100644 index 00000000..03609316 --- /dev/null +++ b/docs/adr/0011-automatable-and-value-density-and-CVSSv4.md @@ -0,0 +1,50 @@ +--- + +status: "accepted" +date: 2024-02-23 +deciders: adh, jspring + +--- +# Correspondence between Automatable v2.0.0, Value Density v1.0.0, and CVSS v4 + +## Context and Problem Statement + +Two SSVC decision points happen to match two CVSS v4 supplemental metrics. +This ADR is to make clear what the SSVC support plan is in regards to this overlap for future versions of these decision points and metrics. + + +## Decision Drivers + +* The SSVC and CVSS communities have productively shared ideas and concepts in the past. These two decision points are an example. It was a relatively long process to propose these decision points as CVSS metrics, take feedback from the CVSS community, get text approved, and then port those changes over to SSVC. This all happened several years before we had this formalized decision documentation process within SSVC. + +## Considered Options + +* No support, expressed or implied, by either group +* SSVC project commits to mirroring any changes made to CVSS +* CVSS SIG commits to mirroring any changes made by the SSVC project +* Both the second and third options, leading to joint decision making on these two decision points / metrics. + +## Decision Outcome + +Chosen option: "No support, expressed or implied, by either group", because +there are no structured agreements in place that could create a service expectation for any continued synchronization going forwards. +The CVSS SIG is an independent group, even if there may be some overlap with the SSVC community, and SSVC cannot require or expect any changes by CVSS. +While SSVC may mirror any changes the CVSS SIG makes to these metrics in the future, that change should be considered by the SSVC community indepdently on its merits, through the normal change management processes for suggestions to amend decision points. + + +### Consequences + +* Good, because low overhead -- no additional organizational structures +* Good, because leaves the opportunity for continued synchronization open if everyone agrees +* Bad, because no guarantee of future synchronization + + + +### Confirmation + +The implementation of this decision is confirmed by continued use of SSVC community change management proceedures for these decision points independent of formal updates to CVSS. + +## More Information + +This decision could hypothetically be revisited at the request of the CVSS SIG. + diff --git a/docs/adr/index.md b/docs/adr/index.md index 90337ccf..eb58185e 100644 --- a/docs/adr/index.md +++ b/docs/adr/index.md @@ -22,6 +22,7 @@ the decision records that have been made. - [0008 - Decision Points are Ordered Sets](0008-decision-points-are-ordered-sets.md) - [0009 - Outcomes are Ordered Sets](0009-outcomes-are-ordered-sets.md) - [0010 - Outcome Sets are separate from Decision Point Groups](0010-outcome-sets-are-separate-from-decision-point-groups.md) +- [0011 - Correspondence between Automatable v2.0.0, Value Density v1.0.0, and CVSS v4](0011-automatable-and-value-density-and-CVSSv4.md) ## Rejected Records From 2590cad7a192e014c311ab887bbc28b82b9b8363 Mon Sep 17 00:00:00 2001 From: ccullen-cert <145690209+ccullen-cert@users.noreply.github.com> Date: Wed, 28 Feb 2024 13:31:52 -0500 Subject: [PATCH 095/113] Ccullen cert patch 2 (#512) * Update index.md * Update items_with_same_priority.md * Update items_with_same_priority.md * Update prepare.md * Update index.md * Update index.md * Update index.md * Update prepare.md * add call-out box, copy edit --------- Co-authored-by: Allen D. Householder --- docs/howto/bootstrap/prepare.md | 16 ++++++++++++++++ docs/index.md | 2 +- docs/topics/items_with_same_priority.md | 4 ++-- 3 files changed, 19 insertions(+), 3 deletions(-) diff --git a/docs/howto/bootstrap/prepare.md b/docs/howto/bootstrap/prepare.md index 6a26200b..710aab40 100644 --- a/docs/howto/bootstrap/prepare.md +++ b/docs/howto/bootstrap/prepare.md @@ -3,6 +3,22 @@ Preparing to use SSVC involves defining a decision you want to make, the information you need to make that decision, and the policy you want to use to make that decision. +!!! tip "Stakeholder Involvement" + + Multiple organizational stakeholders should be involved in the SSVC adoption process. + + - _Risk Owners_ must be involved in the development of the risk management policy represented by SSVC. + - _Vulnerability Management_ stakeholders, including IT Security and IT Service Management (ITSM), should + be involved in the decision modeling and data mapping processes as well. + - _Other Roles_ depend on the organization and specific decision models being developed. For example, a Supplier + organization could include development and possibly service operations roles in the decision modeling process. + A Deployer organization might include safety and incident response roles. + + Stakeholder roles and responsibilities can vary across organizations, however the contextual knowledge they can + bring to the decision making process is essential. SSVC adoption is not just a process for the security team or + technical staff. + + Here is a diagram of the preparation process: ```mermaid diff --git a/docs/index.md b/docs/index.md index 686dbd3a..1dbe5e16 100644 --- a/docs/index.md +++ b/docs/index.md @@ -58,4 +58,4 @@ We have organized the SSVC documentation into four main sections:
-{% include-markdown "_includes/helping_out.md" heading-offset=1 %} \ No newline at end of file +{% include-markdown "_includes/helping_out.md" heading-offset=1 %} diff --git a/docs/topics/items_with_same_priority.md b/docs/topics/items_with_same_priority.md index 9c1b06da..62fbee1b 100644 --- a/docs/topics/items_with_same_priority.md +++ b/docs/topics/items_with_same_priority.md @@ -8,9 +8,9 @@ The priority is equivalent. !!! tip "This is not CVSS" This approach may feel uncomfortable since CVSS gives the appearance of a finer grained priority. - CVSS appears to say, + CVSS appears to say, > Not just 4.0 to 6.9 is ‘medium’ severity, but 4.6 is more severe than 4.5. - However, as discussed {== previously (see page 4) ==}, CVSS is designed to be accurate only within +/- 0.5, + However, CVSS is designed to be accurate only within +/- 0.5, and, in practice, is scored with errors of around +/- 1.5 to 2.5 [@allodi2018effect, see Figure 1]. An error of this magnitude is enough to make all of the “normal” range from 4.0 to 6.9 equivalent, because From a805e671d9c20b764e3c491310d3c1dfa352c9bd Mon Sep 17 00:00:00 2001 From: Vijay Sarvepalli Date: Thu, 29 Feb 2024 14:28:37 -0500 Subject: [PATCH 096/113] SSVC Calculator minor updates (#513) --- docs/ssvc-calc/Deployer.json | 48 +- docs/ssvc-calc/css.css | 4 +- docs/ssvc-calc/findex.html | 497 ++++++++++++++++++ docs/ssvc-calc/index.md | 17 + docs/ssvc-calc/{index.html => old_index.html} | 0 mkdocs.yml | 4 +- 6 files changed, 542 insertions(+), 28 deletions(-) create mode 100644 docs/ssvc-calc/findex.html create mode 100644 docs/ssvc-calc/index.md rename docs/ssvc-calc/{index.html => old_index.html} (100%) diff --git a/docs/ssvc-calc/Deployer.json b/docs/ssvc-calc/Deployer.json index bf749350..fb4af309 100644 --- a/docs/ssvc-calc/Deployer.json +++ b/docs/ssvc-calc/Deployer.json @@ -507,168 +507,168 @@ "Priority": "out-of-cycle" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "small", "Automatable": "no", "Human Impact": "low", "Priority": "defer" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "small", "Automatable": "no", "Human Impact": "medium", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "small", "Automatable": "no", "Human Impact": "high", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "small", "Automatable": "no", "Human Impact": "very high", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "small", "Automatable": "yes", "Human Impact": "low", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "small", "Automatable": "yes", "Human Impact": "medium", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "small", "Automatable": "yes", "Human Impact": "high", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "small", "Automatable": "yes", "Human Impact": "very high", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "controlled", "Automatable": "no", "Human Impact": "low", "Priority": "defer" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "controlled", "Automatable": "no", "Human Impact": "medium", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "controlled", "Automatable": "no", "Human Impact": "high", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "controlled", "Automatable": "no", "Human Impact": "very high", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "controlled", "Automatable": "yes", "Human Impact": "low", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "controlled", "Automatable": "yes", "Human Impact": "medium", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "controlled", "Automatable": "yes", "Human Impact": "high", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "controlled", "Automatable": "yes", "Human Impact": "very high", "Priority": "out-of-cycle" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "open", "Automatable": "no", "Human Impact": "low", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "open", "Automatable": "no", "Human Impact": "medium", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "open", "Automatable": "no", "Human Impact": "high", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "open", "Automatable": "no", "Human Impact": "very high", "Priority": "out-of-cycle" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "open", "Automatable": "yes", "Human Impact": "low", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "open", "Automatable": "yes", "Human Impact": "medium", "Priority": "scheduled" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "open", "Automatable": "yes", "Human Impact": "high", "Priority": "out-of-cycle" }, { - "Exploitation": "PoC", + "Exploitation": "poc", "Exposure": "open", "Automatable": "yes", "Human Impact": "very high", diff --git a/docs/ssvc-calc/css.css b/docs/ssvc-calc/css.css index 2a72c66d..6b5deff7 100644 --- a/docs/ssvc-calc/css.css +++ b/docs/ssvc-calc/css.css @@ -1,4 +1,4 @@ -/* css version 2.2.7 */ +/* css version 2.2.8 */ .ssvcvector { color: #7d1d1d; } @@ -16,7 +16,7 @@ padding: 8px; } .exportdiv { - top: 0px; + top: 250px; left: 30%; border-radius: 6px; border: 1px solid #333; diff --git a/docs/ssvc-calc/findex.html b/docs/ssvc-calc/findex.html new file mode 100644 index 00000000..277c9425 --- /dev/null +++ b/docs/ssvc-calc/findex.html @@ -0,0 +1,497 @@ + + + + + + Dryad SSVC Calc App + + + + + + + + + + + + + + + CERT Logo + +
+ + +
+

+ + Dryad - SSVC Calc App + + +
+ (CISA Coordinator v2) +
+ + +

+ +

+ + + + + + + + +
+

+
+
🔍
+ +
+
+
+
+ + + +
+
+
+ +
+
+
+
+ +
+ + +
+ + + + +
+
+
+
+
+ +
+
+
+
Exploitation choices
+ None:   There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability. +
+ PoC:   + (Proof of Concept)One of the following cases is true: (1) private evidence of exploitation is attested but not shared; (2) widespread hearsay attests to exploitation; (3) typical public PoC in places such as Metasploit or ExploitDB; or (4) the vulnerability has a well-known method of exploitation. Some examples of condition (4) are open-source web proxies serve as the PoC code for how to exploit any vulnerability in the vein of improper validation of TLS certificates. As another example, Wireshark serves as a PoC for packet replay attacks on ethernet or WiFi networks. +
+ Active:   Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting. +
+
+
Virulence choices
+ Slow:   Steps 1-4 of the kill chain cannot be reliably automated for this vulnerability for some reason. These steps are reconnaissance, weaponization, delivery, and exploitation. Example reasons for why a step may not be reliably automatable include (1) the vulnerable component is not searchable or enumerable on the network, (2) weaponization may require human direction for each target, (3) delivery may require channels that widely deployed network security configurations block, and (4) exploitation may be frustrated by adequate exploit-prevention techniques enabled by default; ASLR is an example of an exploit-prevention tool. +
+ Rapid:   Steps 1-4 of the of the kill chain can be reliably automated. If the vulnerability allows unauthenticated remote code execution (RCE) or command injection, the response is likely rapid. +
+
+
Technical Impact
+ Partial:   The exploit gives the adversary limited control over, or information exposure about, the behavior of the software that contains the vulnerability. Or the exploit gives the adversary an importantly low stochastic opportunity for total control. In this context, “low” means that the attacker cannot reasonably make enough attempts to overcome the low chance of each attempt not working. Denial of service is a form of limited control over the behavior of the vulnerable component. +
+ Total:   The exploit gives the adversary total control over the behavior of the software, or it gives total disclosure of all information on the system that contains the vulnerability. +
+
+ +
Mission Prevelance choices
+ Minimal:   Neither support nor essential apply. The vulnerable component may be used within the entities, but it is not used as a mission-essential component nor does it support (enough) mission essential functions. +
+ Support:   The operation of the vulnerable component merely supports mission essential functions for two or more entities. + EssentialThe vulnerable component directly provides capabilities that constitute at least one MEF for at least one entity, and failure may (but need not) lead to overall mission failure. +
+
+
Vulnerability Scoring Decisions
+ Track   The vulnerability does not require attention outside of Vulnerability Management (VM) at this time. Continue to track the situation and reassess the severity of vulnerability if necessary. +
+ Track *   Track these closely, especially if mitigation is unavailable or difficult. Recommended that analyst discuss with other ana-lysts and get a second opinion. +
+ Attend   The vulnerability requires to be attended to by stakeholders outside VM. The action is a request to others for assistance / information / details, as well as a potential publication about the issue. +
+ Act   The vulnerability requires immediate action by the relevant leadership. The action is a high-priority meeting among the relevant supervisors to decide how to respond. +
+ +
+ + + + + + + + +
+ Determining Mission & Well-being impact value +

 

Public Well-Being Impact


Minimal

Material

Irreversible

Mission Prevalence

Minimal

Low

Medium

High

Support

Medium

Medium

High

Essential

High

High

High

+
+ + + +
+ +
Public Well-being Impact Decision Values
+ + +
+

Impact

Type of Harm

Description

Minimal

All

The effect is below the threshold for all aspects described in material.

Material
(Any one or more of these conditions hold.)

Physical harm

Physical distress and injuries for users (not operators) of the system.

Operator
resiliency

If the operator is expected to be able to keep the cyber-physical system safely operating (that is, prevents one of the other types of harm), then select this option if one of these three apply: system operator must react to exploitation of the vulnerability to maintain safe system state but operator actions would be within their capabilities; OR significant distraction or discomfort to operators; OR causes significant occupational safety hazard.

System
resiliency

Cyber-physical system’s safety margin effectively eliminated but no actual harm; OR failure of cyber-physical system functional capabilities that support safe operation.

Environment

Major externalities (property damage, environmental damage, etc.) imposed on other parties.

Financial

Financial losses that likely lead to bankruptcy of multiple persons.

Psychological

Widespread emotional or psychological harm, sufficient to be cause for counselling or therapy, to populations of people.

Irreversible (Any one or more of these conditions hold.)

Physical harm

Multiple fatalities likely.

Operator
resiliency

Operator is incapacitated, where operator usually maintains safe cyber-physical system operations, and so other harms at this level are likely.

System
resiliency

Total loss of whole cyber-physical system of which the software is a part.

Environment

Extreme or serious externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) imposed on other parties.

Financial

Social systems (elections, financial grid, etc.) supported by the software are destabilized and potentially collapse.

Psychological

N/A

+
+
+ +
+ Stakeholder-Specific Vulnerability Categorization (SSVC) +
+ version 2 (October 2020) +
+
+

Introduction:

+

+ Our proposed SSVC approach for vulnerability prioritization takes the form of decision trees. This decision tree can be adapted for different vulnerability management stakeholders such as patch developers and patch appliers. In this instance of Drayd - SSVC calculator app, SSVC is being prototyped for CISA in their unique role as advisors to be able to provide decision support to various stakeholders and influence their prioritization of vulnerabilities. +

+
+
+

Decision Tree Usage:

+

+ Click on the button to see + the complete decision tree at a glance. Each circle + + + + + + + represents a decision point or + stage/fork in the decision tree. You can move your mouse over each circle + to get a glimpse at the definition of the choices you can make after that stage/fork. + The path (branch) leading to the next stage fork is labeled + + + + + partial + + + also as it leads you to the next stage/fork represented by a circle. +

+
+

+ When using for a new SSVC calculation with + +
+ You can move your mouse over circle + + + + + + + or on the text + + Exploitation + that represents a stage/fork in the decision tree + to get information + on choices you can make for + your next stage/fork of the tree. + You will see each branch will also be be labeled + + + + + partial + + + that leads you to the next stage/fork. + You can make the appropriate choice by clicking on the text "partial" or on the + circle where your chosen path ends or terminates. Follow these steps on the decision tree. + When prompted for more complex decision making like + + Mission & Well-Being Impact, you will be presented with more choices, + you can click on + ? to get more help in + understanding and making the right choices. +

+

+ Mission & Well-being + is a + cumulative decision that is comprised of + + Mission Prevelance and + + Public Well-Being Impact + . +

+
+
+
+
+
+
+
+

Export Calculated Score

+ +
+
+ + + + + + + + + + + + +
+ +
+ +
+
+ + + + + + + + +
+ + +
+ + + + Include decision tree in export + +
+ Contact: + +
+
+
+ +
+ JSON + PDF + +
+
+
+
+
+
+ + + + + diff --git a/docs/ssvc-calc/index.md b/docs/ssvc-calc/index.md new file mode 100644 index 00000000..2152c657 --- /dev/null +++ b/docs/ssvc-calc/index.md @@ -0,0 +1,17 @@ +# SSVC Calculator + + + + + diff --git a/docs/ssvc-calc/index.html b/docs/ssvc-calc/old_index.html similarity index 100% rename from docs/ssvc-calc/index.html rename to docs/ssvc-calc/old_index.html diff --git a/mkdocs.yml b/mkdocs.yml index a8648e72..164a6c4a 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -4,7 +4,7 @@ nav: - Home: 'index.md' - Learning SSVC: - Intro: 'tutorials/index.md' - - SSVC Calculator: 'ssvc-calc/index.html' + - SSVC Calculator: 'ssvc-calc/index.md' - SSVC How-To: - Overview: 'howto/index.md' - Getting Started with SSVC: @@ -73,7 +73,7 @@ nav: - Policy Generator: 'reference/code/policy_generator.md' - Outcomes: 'reference/code/outcomes.md' - Doctools: 'reference/code/doctools.md' - - Calculator: 'ssvc-calc/index.html' + - Calculator: 'ssvc-calc/index.md' - About: - Intro: 'about/index.md' - Community Engagement: 'about/contributing.md' From ea2b9004fa2a1057ec7997cf76de248cd9fb77a0 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 29 Feb 2024 15:27:57 -0500 Subject: [PATCH 097/113] Add Calculator blurb to `Learning SSVC` (#515) * add a small calculator blurb on the `Learning SSVC` page * remove the redundant link to the calculator from the left hand nav. It's linked from the page directly, and it's also in the site top nav to begin with. --- docs/tutorials/index.md | 6 ++++++ mkdocs.yml | 4 +--- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md index 24920ff0..de1f96eb 100644 --- a/docs/tutorials/index.md +++ b/docs/tutorials/index.md @@ -2,6 +2,12 @@ {== todo add intro ==} +!!! tip "SSVC Calculator" + + We've created a simple [SSVC Calculator](../ssvc-calc/index.md) to help you understand how SSVC decision models work. + The decisions modeled in the calculator are based on the [Supplier](../howto/supplier_tree.md), + [Deployer](../howto/deployer_tree.md), and [Coordinator](../howto/coordination_intro.md) decision models. + ## Videos | Source | Video | diff --git a/mkdocs.yml b/mkdocs.yml index 164a6c4a..bbc7aef6 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -2,9 +2,7 @@ site_name: "SSVC: Stakeholder-Specific Vulnerability Categorization" copyright: Copyright © 2024 Carnegie Mellon University. nav: - Home: 'index.md' - - Learning SSVC: - - Intro: 'tutorials/index.md' - - SSVC Calculator: 'ssvc-calc/index.md' + - Learning SSVC: 'tutorials/index.md' - SSVC How-To: - Overview: 'howto/index.md' - Getting Started with SSVC: From 22c7870e7d46f4e926af83ac80ce360e59f5f72b Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 1 Mar 2024 12:47:44 -0500 Subject: [PATCH 098/113] add google analytics --- mkdocs.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mkdocs.yml b/mkdocs.yml index bbc7aef6..a3eb916c 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -146,6 +146,9 @@ markdown_extensions: - pymdownx.tilde - tables extra: + analytics: + provider: google + property: G-87WECW6HCS social: - icon: material/message-question link: https://github.com/CERTCC/SSVC/issues/new?template=question.md From 44c0dbd3d73b15c39b431d822dacf3fe3f429c97 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 1 Mar 2024 13:07:19 -0500 Subject: [PATCH 099/113] add cookie consent prompt --- mkdocs.yml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mkdocs.yml b/mkdocs.yml index a3eb916c..9a8e4460 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,5 +1,7 @@ site_name: "SSVC: Stakeholder-Specific Vulnerability Categorization" -copyright: Copyright © 2024 Carnegie Mellon University. +copyright: > + Copyright © 2024 Carnegie Mellon University. +
Change cookie settings nav: - Home: 'index.md' - Learning SSVC: 'tutorials/index.md' @@ -149,6 +151,13 @@ extra: analytics: provider: google property: G-87WECW6HCS + consent: + title: About our use of cookies on this site + description: >- + We use cookies to measure the effectiveness of our documentation and whether users + find what they're searching for. With your consent, you're helping us to + make our documentation better. + See our Privacy Notice for more. social: - icon: material/message-question link: https://github.com/CERTCC/SSVC/issues/new?template=question.md From d5fd9e4f1e479f7c60da9e5f5e7c7f626db59394 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 1 Mar 2024 13:08:01 -0500 Subject: [PATCH 100/113] update copyright year(s) --- mkdocs.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mkdocs.yml b/mkdocs.yml index 9a8e4460..1cc17818 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,6 +1,6 @@ site_name: "SSVC: Stakeholder-Specific Vulnerability Categorization" copyright: > - Copyright © 2024 Carnegie Mellon University. + Copyright © 2019-2024 Carnegie Mellon University.
Change cookie settings nav: - Home: 'index.md' From 5ef7125ce9b38b9eefd21cb95d7f6197f2a34cd9 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 4 Mar 2024 11:04:12 -0500 Subject: [PATCH 101/113] Bump the mkdocs group with 3 updates (#521) Bumps the mkdocs group with 3 updates: [mkdocs-bibtex](https://github.com/shyamd/mkdocs-bibtex), [mkdocs-material](https://github.com/squidfunk/mkdocs-material) and [mkdocstrings](https://github.com/mkdocstrings/mkdocstrings). Updates `mkdocs-bibtex` from 2.12.0 to 2.14.1 - [Release notes](https://github.com/shyamd/mkdocs-bibtex/releases) - [Commits](https://github.com/shyamd/mkdocs-bibtex/compare/v2.12.0...v2.14.1) Updates `mkdocs-material` from 9.5.11 to 9.5.12 - [Release notes](https://github.com/squidfunk/mkdocs-material/releases) - [Changelog](https://github.com/squidfunk/mkdocs-material/blob/master/CHANGELOG) - [Commits](https://github.com/squidfunk/mkdocs-material/compare/9.5.11...9.5.12) Updates `mkdocstrings` from 0.24.0 to 0.24.1 - [Release notes](https://github.com/mkdocstrings/mkdocstrings/releases) - [Changelog](https://github.com/mkdocstrings/mkdocstrings/blob/main/CHANGELOG.md) - [Commits](https://github.com/mkdocstrings/mkdocstrings/compare/0.24.0...0.24.1) --- updated-dependencies: - dependency-name: mkdocs-bibtex dependency-type: direct:production update-type: version-update:semver-minor dependency-group: mkdocs - dependency-name: mkdocs-material dependency-type: direct:production update-type: version-update:semver-patch dependency-group: mkdocs - dependency-name: mkdocstrings dependency-type: direct:production update-type: version-update:semver-patch dependency-group: mkdocs ... Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- requirements.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/requirements.txt b/requirements.txt index 31c6f3de..d559b49e 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,10 +1,10 @@ mkdocs==1.5.3 -mkdocs-bibtex==2.12.0 +mkdocs-bibtex==2.14.1 mkdocs-include-markdown-plugin==6.0.4 mkdocs-table-reader-plugin==2.1.0 -mkdocs-material==9.5.11 +mkdocs-material==9.5.12 mkdocs-material-extensions==1.3.1 -mkdocstrings==0.24.0 +mkdocstrings==0.24.1 mkdocstrings-python==1.8.0 mkdocs-print-site-plugin==2.3.6 dataclasses-json==0.6.4 From 7007da9a03cd97550ba4af7a6d376d6d3cdc7423 Mon Sep 17 00:00:00 2001 From: Vijay Sarvepalli Date: Mon, 4 Mar 2024 11:08:31 -0500 Subject: [PATCH 102/113] Display updates for iframe (#520) Co-authored-by: Allen D. Householder --- docs/ssvc-calc/css.css | 8 ++++++-- docs/ssvc-calc/ssvc.js | 14 ++++++++++++-- 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/ssvc-calc/css.css b/docs/ssvc-calc/css.css index 6b5deff7..ecf4f301 100644 --- a/docs/ssvc-calc/css.css +++ b/docs/ssvc-calc/css.css @@ -110,7 +110,7 @@ } #mpopup { font-size: smaller; - max-width: 400px; + max-width: 300px; } #mgraph { margin-left: 600px; @@ -350,8 +350,9 @@ body.whitebody max-width:40%; } #mpopup { - max-width: 600px; + max-width: 400px; overflow-y: auto; + text-shadow: none; /* Just one greater than modal */ z-index: 1051; display: none; @@ -453,3 +454,6 @@ pre { .btn-dark.btn-bordered:hover { border: 2px solid white; } +textPath { +cursor: pointer; +} diff --git a/docs/ssvc-calc/ssvc.js b/docs/ssvc-calc/ssvc.js index 75955f34..812bf022 100644 --- a/docs/ssvc-calc/ssvc.js +++ b/docs/ssvc-calc/ssvc.js @@ -1019,6 +1019,11 @@ function generate_uuid() { return uuid+'-'+Math.random().toString(16).substr(2,12) } +function togglehelp() { + $('#mpopup').toggleClass("d-none"); + $('#frbcbx').prop("checked",$('#mpopup').hasClass("d-none")); +} + function draw_graph() { var margin = {top: 20, right: 120, bottom: 20, left: 120}, width = 1060 - margin.right - margin.left, @@ -1049,6 +1054,11 @@ function draw_graph() { } $('#zoomcontrol').show(); $('#zoomcontrol input').val(100); + $('#graph').html($('
').attr({"id":"frbdiv"}).css({"position": "fixed","font-size": "x-small"}) + .on("click",togglehelp).append($('') + .attr({"id": "frbcbx","type": "checkbox"}) + .css({"width": "10px"})) + .append($('').html("Hide help text"))); svg = d3.select("#graph").append("svg") .attr("xmlns","http://www.w3.org/2000/svg") .attr("preserveAspectRatio","none") @@ -1057,7 +1067,7 @@ function draw_graph() { .attr("height", svg_height) .append("g") .attr("transform", default_translate) - .attr("id","pgroup") + .attr("id","pgroup"); root = treeData[0]; root.x0 = height / 2; @@ -1377,7 +1387,7 @@ function showdiv(d) { } } function hidediv(d) { - $('#mpopup').hide() + $('#mpopup').hide(); } function checkclose() { /* */ From 5507f11caf9eec8b3c936ead273ccda8b1b6d0e0 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Mon, 4 Mar 2024 16:29:06 -0500 Subject: [PATCH 103/113] Copy edits & punch list (#524) Co-authored-by: Laurie Tyzenhaus --- docs/_includes/_cvss4_question.md | 5 + docs/_includes/_scrollable_table.md | 3 + docs/howto/bootstrap/collect.md | 50 +++++--- docs/howto/bootstrap/use.md | 13 +- docs/howto/coordination_triage_decision.md | 2 + docs/howto/deployer_tree.md | 2 + docs/howto/index.md | 5 +- .../reference/decision_points/exploitation.md | 13 +- .../decision_points/technical_impact.md | 8 +- docs/reference/decision_points/utility.md | 4 +- docs/topics/asset_management.md | 2 +- docs/topics/decision_points_as_bricks.md | 2 +- docs/topics/evaluation_of_draft_trees.md | 111 ++++++++++-------- docs/topics/future_work.md | 7 +- docs/topics/information_sources.md | 12 +- docs/topics/items_with_same_priority.md | 6 +- docs/topics/related_systems.md | 10 +- docs/topics/worked_example.md | 12 +- docs/tutorials/index.md | 45 ++++++- 19 files changed, 212 insertions(+), 100 deletions(-) create mode 100644 docs/_includes/_cvss4_question.md create mode 100644 docs/_includes/_scrollable_table.md diff --git a/docs/_includes/_cvss4_question.md b/docs/_includes/_cvss4_question.md new file mode 100644 index 00000000..d8b2cd6a --- /dev/null +++ b/docs/_includes/_cvss4_question.md @@ -0,0 +1,5 @@ +!!! question inline end "What about CVSS v4?" + + Since this documentation was written, CVSS v4 has been released. + While we plan to address CVSS v4 in a future update to the SSVC documentation, we are + retaining our CVSS v3.1 content because it remains the most widely used version of CVSS. diff --git a/docs/_includes/_scrollable_table.md b/docs/_includes/_scrollable_table.md new file mode 100644 index 00000000..640654d8 --- /dev/null +++ b/docs/_includes/_scrollable_table.md @@ -0,0 +1,3 @@ +!!! tip "Scroll to the right to see the full table" + + The table below is scrollable to the right. diff --git a/docs/howto/bootstrap/collect.md b/docs/howto/bootstrap/collect.md index 9bb57d9b..53381718 100644 --- a/docs/howto/bootstrap/collect.md +++ b/docs/howto/bootstrap/collect.md @@ -59,6 +59,7 @@ That caveat notwithstanding, some automation is possible. 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 @@ -66,17 +67,19 @@ 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. + An obvious example of this is the [Mission Impact](../../reference/decision_points/mission_impact.md) decision point. + To answer this, a deployer must analyze their Mission Essential Functions (MEFs), how they interrelate, and how they are supported. + -!!! example "Evidence of Exposure" +!!! example "Evidence of System Exposure" - Exposure is similar; answering that decision point requires an asset inventory, adequate understanding of the network + [System Exposure](../../reference/decision_points/system_exposure.md) 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 + +Once the deployer has the situational awareness to understand their Mission Essential Functions or System 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 @@ -94,36 +97,47 @@ deployer may want to use that information to favor the latter. 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" +!!! tip "Default Exploitation Values" + + [*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 System 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 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). + !!! 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). + [*marginal*](../../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). + +!!! example "Using Defaults" -!!! 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). + Applying these defaults to the [deployer decision model](../deployer_tree.md) -The resulting decision set `{none, open, yes, medium}` results in a scheduled patch application in our recommended -deployer tree. + - *Exploitation*: none + - *System Exposure*: open + - *Automatable*: yes + - *Human Impact*: medium (combination of Safety and Mission Impacts) + - *Safety Impact*: marginal + - *Mission Impact*: support crippled + results in a `scheduled` patch application. diff --git a/docs/howto/bootstrap/use.md b/docs/howto/bootstrap/use.md index 282eab86..cbf9a4db 100644 --- a/docs/howto/bootstrap/use.md +++ b/docs/howto/bootstrap/use.md @@ -1,6 +1,6 @@ # Use SSVC -The [preparation](prepare.md) is complete, data is being [collected](collect.md), and now it is time to use +The [preparation](prepare.md) is complete, data has been [collected](collect.md), and now it is time to use SSVC to make decisions about how to respond to vulnerabilities. ```mermaid @@ -79,7 +79,7 @@ flowchart LR The service providers in previous examples might need to notify customers of the vulnerability and schedule maintenance windows to apply patches. Medical device manufacturers might need to develop patches, notify regulators of the vulnerability, and provide - instructions to hospital users for applying patches. + instructions to deployers (e.g., device maintainers at hospitals) for applying patches. SSVC does not prescribe any particular response process, but it does provide a structured way to make decisions within the response process. @@ -149,13 +149,18 @@ The merit in this “list all values” approach emerges when the stakeholder kn !!! example "When Some Values Are Known (But Others Are Not)" - 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). + Extending the previous 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). {% include-markdown "../../_generated/decision_points/value_density.md" %} {% include-markdown "../../_generated/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). + Therefore they could rule out [super effective](../../reference/decision_points/utility.md) + for [Utility](../../reference/decision_points/utility.md) + but not [laborious](../../reference/decision_points/utility.md) + or [efficient](../../reference/decision_points/utility.md). + In this case, the analyst could usefully restrict [Utility](../../reference/decision_points/utility.md) to one of [laborious](../../reference/decision_points/utility.md) or [efficient](../../reference/decision_points/utility.md) + while leaving [Automatability](../../reference/decision_points/automatable.md) open. 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. diff --git a/docs/howto/coordination_triage_decision.md b/docs/howto/coordination_triage_decision.md index 4519411c..b85dd4cd 100644 --- a/docs/howto/coordination_triage_decision.md +++ b/docs/howto/coordination_triage_decision.md @@ -109,5 +109,7 @@ height = "700" /> ### Table of Values +{% include-markdown "../_includes/_scrollable_table.md" heading-offset=1 %} + {{ read_csv('coord-triage-options.csv') }} diff --git a/docs/howto/deployer_tree.md b/docs/howto/deployer_tree.md index f53b9522..68853bc0 100644 --- a/docs/howto/deployer_tree.md +++ b/docs/howto/deployer_tree.md @@ -119,6 +119,8 @@ More detail about each of these decision points is provided at the links above, {% include-markdown "../_generated/decision_points/utility.md" %} {% include-markdown "../_generated/decision_points/human_impact.md" %} +In the _Human Impact_ table above, *MEF* stands for Mission Essential Function. + ## Deployer Decision Model Below we provide an example deployer prioritization policy that maps the decision points just listed to the outcomes described above. diff --git a/docs/howto/index.md b/docs/howto/index.md index 91271235..b3331037 100644 --- a/docs/howto/index.md +++ b/docs/howto/index.md @@ -54,7 +54,8 @@ The definition of choices can take a logical form, such as: - 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). + +This example logical statement is captured in [row 34 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 documentation, we primarily represent a full set of guidance on how one stakeholder will make a decision as a **decision tree**. @@ -64,7 +65,7 @@ fit your organization's needs.
-- :material-stairs: [Bootstrapping SSVC](bootstrap/index.md) +- :material-stairs: [Getting Started with SSVC](bootstrap/index.md) - :material-factory: [Supplier Decision Model](supplier_tree.md) - :material-server-network: [Deployer Decision Model](deployer_tree.md) - :material-steering: [Coordinator Decision Models](coordination_intro.md) diff --git a/docs/reference/decision_points/exploitation.md b/docs/reference/decision_points/exploitation.md index 4b99c7ec..58b398c2 100644 --- a/docs/reference/decision_points/exploitation.md +++ b/docs/reference/decision_points/exploitation.md @@ -30,15 +30,18 @@ The intent of this measure is the present state of exploitation of the vulnerabi ## CWE-IDs for *PoC* + 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* since that meets condition (3) in - the definition. + 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* since that meets condition (3) in the definition. + +{% include-markdown "../../_includes/_scrollable_table.md" heading-offset=1 %} {{ read_csv('cwe/possible-cwe-with-poc-examples.csv') }} diff --git a/docs/reference/decision_points/technical_impact.md b/docs/reference/decision_points/technical_impact.md index b47fe2d3..f7280b9a 100644 --- a/docs/reference/decision_points/technical_impact.md +++ b/docs/reference/decision_points/technical_impact.md @@ -2,7 +2,7 @@ {% include-markdown "../../_generated/decision_points/technical_impact.md" %} -When evaluating [*Technical Impact*](technical_impact.md), recall the scope definition in the [Scope Section](../../topics/scope.md). +When evaluating *Technical Impact*, 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. @@ -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.md) amounts to assessing the degree of control over the vulnerable component the attacker stands to gain by exploiting the vulnerability. + Assessing *Technical Impact* 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,7 @@ 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.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). + If you find a vulnerability that should have *total* *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). diff --git a/docs/reference/decision_points/utility.md b/docs/reference/decision_points/utility.md index d394b7dc..93e94124 100644 --- a/docs/reference/decision_points/utility.md +++ b/docs/reference/decision_points/utility.md @@ -14,7 +14,9 @@ This is a compound decision point, therefore it is a notational convenience. *Utility* is independent from the state of [*Exploitation*](exploitation.md), which measures whether a set of adversaries have ready access to exploit code or are in fact exploiting the vulnerability. In economic terms, [*Exploitation*](exploitation.md) measures whether the **capital cost** of producing reliable exploit code has been paid or not. *Utility* estimates the **marginal cost** of each exploitation event. -More plainly, *Utility* is about how much an adversary might benefit from a campaign using the vulnerability in question, whereas [*Exploitation*](exploitation.md) is about how easy it would be to start such a campaign or if one is already underway. + +Whereas [*Exploitation*](exploitation.md) is about how easy it would be to start such a campaign or if one is already underway, +*Utility* is about how much an adversary might benefit from a campaign using the vulnerability in question. Heuristically, we base Utility on a combination of the value density of vulnerable components and whether potential exploitation is automatable. This framing makes it easier to analytically derive these categories from a description of the vulnerability and the affected component. diff --git a/docs/topics/asset_management.md b/docs/topics/asset_management.md index 7ed99ae5..95279f87 100644 --- a/docs/topics/asset_management.md +++ b/docs/topics/asset_management.md @@ -32,7 +32,7 @@ Once the organization remediates or mitigates all the high-priority vulnerabilit Asset management and risk management also drive some of the up-front work an organization would need to do to gather some of the necessary information. 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. +Emerging standards like the [Software Bill of Materials](https://www.cisa.gov/sbom) (SBOM) 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](../reference/decision_points/mission_impact.md)) plan and process in place, then SSVC provides some guidance as to what information is important to vulnerability diff --git a/docs/topics/decision_points_as_bricks.md b/docs/topics/decision_points_as_bricks.md index 227f6c8f..c60bc044 100644 --- a/docs/topics/decision_points_as_bricks.md +++ b/docs/topics/decision_points_as_bricks.md @@ -50,7 +50,7 @@ From that starting point, there are a few different ways you might proceed: ### Follow the examples as provided For many people, this is the experience they want. -They want to build the model exactly as it is pictured on the box, and for that purpose they can follow the instructions provided. +They want to build the model exactly as it is pictured on the box, and so they will simply follow the instructions provided. ### Adapt the examples to suit your needs diff --git a/docs/topics/evaluation_of_draft_trees.md b/docs/topics/evaluation_of_draft_trees.md index 0bec4858..4bde0c5c 100644 --- a/docs/topics/evaluation_of_draft_trees.md +++ b/docs/topics/evaluation_of_draft_trees.md @@ -12,9 +12,9 @@ The method of the pilot test is described in [Pilot Methodogy](#pilot-methodolog For this tabletop refinement, we could not select a mathematically representative set of CVEs. The goal was to select a handful of CVEs that would cover diverse types of vulnerabilities. - The CVEs that we used for our tabletop exercises are CVE-2017-8083, CVE-2019-2712, CVE-2014-5570, and CVE-2017-5753. + The CVEs that we used for our tabletop exercises are [CVE-2017-8083](https://nvd.nist.gov/vuln/detail/CVE-2017-8083), [CVE-2019-2712](https://nvd.nist.gov/vuln/detail/CVE-2019-2712), [CVE-2014-5570](https://nvd.nist.gov/vuln/detail/CVE-2014-5570), and [CVE-2017-5753](https://nvd.nist.gov/vuln/detail/CVE-2017-5753). We discussed each one from the perspective of supplier and deployer. - We evaluated CVE-2017-8083 twice because our understanding and descriptions had changed materially after the first three CVEs (six evaluation exercises). + We evaluated [CVE-2017-8083](https://nvd.nist.gov/vuln/detail/CVE-2017-8083) twice because our understanding and descriptions had changed materially after the first three CVEs (six evaluation exercises). After we were satisfied that the decision trees were clearly defined and captured our intentions, we began the formal evaluation of the draft trees, which we describe in the next section. The pilot study tested inter-rater agreement of decisions reached. Each author played the role of an analyst in both stakeholder groups (supplying and deploying) for nine vulnerabilities. We selected these nine vulnerabilities based on expert analysis, with the goal that the nine cases cover a useful series of vulnerabilities of interest. Specifically, we selected three vulnerabilities to represent safety-critical cases, three to represent regulated-systems cases, and three to represent general computing cases. @@ -24,9 +24,20 @@ However, we did standardize the set of evidence that was taken to be true for th 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. - -The structure of the pilot test is as follows. Table 11 provides an example of the information provided to each analyst. The supplier portfolio details use ~~strikeout font~~ because this decision item was removed after the pilot. The decision procedure for each case is as follows: for each analyst, for each vulnerability, for each stakeholder group, do the following. +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 is left as future work. +In some domains, namely exploit availability, we have started that work in parallel. + +The structure of the pilot test is as follows. The next table provides an example of the information provided to each analyst. The supplier portfolio details use ~~strikeout font~~ because this decision item was removed after the pilot. The decision procedure for each case is as follows: for each analyst, for each vulnerability, for each stakeholder group, do the following. 1. Start at the root node of the relevant decision tree (deployer or supplier). @@ -37,27 +48,27 @@ The structure of the pilot test is as follows. Table 11 provides an example of t 4. Repeat this decision-and-evidence process until the analyst reaches a leaf node in the tree. Table: Example of Scenario Information Provided to Analysts (Using -CVE-2019-9042 as the Example) - -| Information Item | Description Provided to Analysts | -| :--- | :----------- | -| Use of Cyber-Physical System | Sitemagic’s content management system (CMS) seems to be fairly popular among smaller businesses because it starts out with a free plan to use it. Then it gradually has small increments in payment for additional features. Its ease-of-use, good designs, and one-stop-shopping for businesses attracts a fair number of clients. Like any CMS, it “manages the creation and modification of digital content. These systems typically support multiple users in a collaborative environment, allowing document management with different styles of governance and workflows. Usually the content is a website” \([Wikipedia](https://en.wikipedia.org/w/index.php?title=Content_management_system&oldid=913022120), 2019\) | -| State of Exploitation | Appears to be active exploitation of this vulnerability according to NVD. They have linked to the exploit: http://www.iwantacve.cn/index.php/archives/116/. | -| ~~Developer Portfolio Details~~ | ~~Sitemagic is an open-source project. The only thing the brand name applies to is the CMS, and it does not appear to be part of another open-source umbrella. The project is under active maintenance (i.e., it is not a dead project).~~ | -| Technical Impact of Exploit | An authenticated user can upload a .php file to execute arbitrary code with system privileges. | -| Scenario Blurb | We are a small business that uses Sitemagic to help run our business. Sitemagic handles everything from digital marketing and site design to facilitating the e-commerce transactions of the website. We rely on this website heavily, even though we do have a brick-and-mortar store. Many times, products are not available in-store, but are available online, so we point many customers to our online store. | -| Deployer Mission | We are a private company that must turn a profit to remain competitive. We want to provide customers with a valuable product at a reasonable price, while still turning a profit to run the business. As we are privately held (and not public), we are free to choose the best growth strategy (that is, we are not legally bound to demonstrate quarterly earnings for shareholders and can take a longer-term view if it makes us competitive). | -| Deployment of Affected System | We have deployed this system such that only the web designer Cheryl and the IT admin Sally are allowed to access the CMS as users. They login through a password-protected portal that can be accessed anywhere in the world for remote administration. The CMS publishes content to the web, and that web server and site are publicly available. | +[CVE-2019-9042](https://nvd.nist.gov/vuln/detail/CVE-2019-9042) as the Example) + +| Information Item | Description Provided to Analysts | +|:--------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Use of Cyber-Physical System | Sitemagic’s content management system (CMS) seems to be fairly popular among smaller businesses because it starts out with a free plan to use it. Then it gradually has small increments in payment for additional features. Its ease-of-use, good designs, and one-stop-shopping for businesses attracts a fair number of clients. Like any CMS, it “manages the creation and modification of digital content. These systems typically support multiple users in a collaborative environment, allowing document management with different styles of governance and workflows. Usually the content is a website” ([Wikipedia](https://en.wikipedia.org/w/index.php?title=Content_management_system&oldid=913022120), 2019) | +| State of Exploitation | Appears to be active exploitation of this vulnerability according to NVD. They have linked to the exploit: http://www.iwantacve.cn/index.php/archives/116/. | +| ~~Developer Portfolio Details~~ | ~~Sitemagic is an open-source project. The only thing the brand name applies to is the CMS, and it does not appear to be part of another open-source umbrella. The project is under active maintenance (i.e., it is not a dead project).~~ | +| Technical Impact of Exploit | An authenticated user can upload a .php file to execute arbitrary code with system privileges. | +| Scenario Blurb | We are a small business that uses Sitemagic to help run our business. Sitemagic handles everything from digital marketing and site design to facilitating the e-commerce transactions of the website. We rely on this website heavily, even though we do have a brick-and-mortar store. Many times, products are not available in-store, but are available online, so we point many customers to our online store. | +| Deployer Mission | We are a private company that must turn a profit to remain competitive. We want to provide customers with a valuable product at a reasonable price, while still turning a profit to run the business. As we are privately held (and not public), we are free to choose the best growth strategy (that is, we are not legally bound to demonstrate quarterly earnings for shareholders and can take a longer-term view if it makes us competitive). | +| Deployment of Affected System | We have deployed this system such that only the web designer Cheryl and the IT admin Sally are allowed to access the CMS as users. They login through a password-protected portal that can be accessed anywhere in the world for remote administration. The CMS publishes content to the web, and that web server and site are publicly available. | This test structure produced a series of lists similar in form to the -contents of Table 12. Analysts also noted how much time they spent on +contents of the table below. Analysts also noted how much time they spent on each vulnerability in each stakeholder group. Table: Example Documentation of a Single Decision Point -| Decision Point | Branch Selected | Supporting Evidence | -| :--- | :--- | :------- | -| Exploitation=active | Controlled | The CMS has a limited number of authorized users, and the vulnerability is exploitable only by an authenticated user | +| Decision Point | Branch Selected | Supporting Evidence | +|:--------------------|:------------------|:---------------------------------------------------------------------------------------------------------------------| +| Exploitation=active | Controlled | The CMS has a limited number of authorized users, and the vulnerability is exploitable only by an authenticated user | We evaluated inter-rater agreement in two stages. In the first stage, each analyst independently documented their decisions. This stage produced 18 sets of decisions (nine vulnerabilities across each of two stakeholder groups) per analyst. In the second stage, we met to discuss decision points where at least one analyst differed from the others. If any analyst changed their decision, they appended the information and evidence they gained during this meeting in the “supporting evidence” value in their documentation. No changes to decisions were forced, and prior decisions were not erased, just amended. After the second stage, we calculated some statistical measures of inter-rater agreement to help guide the analysis of problem areas. @@ -78,69 +89,69 @@ Third, the pilot provides a proof of concept method and metric that any vulnerab ### Vulnerabilities used as examples -The vulnerabilities used as case studies are as follows. All quotes are from the [National Vulnerability Database (NVD)](https://nvd.nist.gov/) and are illustrative of the vulnerability; however, during the study each vulnerability was evaluated according to information analogous to that in Table 11. +The vulnerabilities used as case studies are as follows. All quotes are from the [National Vulnerability Database (NVD)](https://nvd.nist.gov/) and are illustrative of the vulnerability; however, during the study each vulnerability was evaluated according to information analogous to that in the scenario table above. ### Safety-Critical Cases - - CVE-2015-5374: “Vulnerability … in \[Siemens\] Firmware variant PROFINET IO for EN100 Ethernet module… Specially crafted packets sent to port 50000/UDP could cause a denial-of-service of the affected device…” + - [CVE-2015-5374](https://nvd.nist.gov/vuln/detail/CVE-2015-5374): “Vulnerability … in \[Siemens\] Firmware variant PROFINET IO for EN100 Ethernet module… Specially crafted packets sent to port 50000/UDP could cause a denial-of-service of the affected device…” - - CVE-2014-0751: “Directory traversal vulnerability in … GE Intelligent Platforms Proficy HMI/SCADA - CIMPLICITY before 8.2 SIM 24, and Proficy Process Systems with CIMPLICITY, allows remote attackers to execute arbitrary code via a crafted message to TCP port 10212, aka ZDI-CAN-1623.” + - [CVE-2014-0751](https://nvd.nist.gov/vuln/detail/CVE-2014-0751): “Directory traversal vulnerability in … GE Intelligent Platforms Proficy HMI/SCADA - CIMPLICITY before 8.2 SIM 24, and Proficy Process Systems with CIMPLICITY, allows remote attackers to execute arbitrary code via a crafted message to TCP port 10212, aka ZDI-CAN-1623.” - - CVE-2015-1014: “A successful exploit of these vulnerabilities requires the local user to load a crafted DLL file in the system directory on servers running Schneider Electric OFS v3.5 with version v7.40 of SCADA Expert Vijeo Citect/CitectSCADA, OFS v3.5 with version v7.30 of Vijeo Citect/CitectSCADA, and OFS v3.5 with version v7.20 of Vijeo Citect/CitectSCADA. If the application attempts to open that file, the application could crash or allow the attacker to execute arbitrary code.” + - [CVE-2015-1014](https://nvd.nist.gov/vuln/detail/CVE-2015-1014): “A successful exploit of these vulnerabilities requires the local user to load a crafted DLL file in the system directory on servers running Schneider Electric OFS v3.5 with version v7.40 of SCADA Expert Vijeo Citect/CitectSCADA, OFS v3.5 with version v7.30 of Vijeo Citect/CitectSCADA, and OFS v3.5 with version v7.20 of Vijeo Citect/CitectSCADA. If the application attempts to open that file, the application could crash or allow the attacker to execute arbitrary code.” ### Regulated Systems Cases - - CVE-2018-14781: “Medtronic insulin pump \[specific versions\] when paired with a remote controller and having the “easy bolus” and “remote bolus” options enabled (non-default), are vulnerable to a capture-replay attack. An attacker can … cause an insulin (bolus) delivery.” + - [CVE-2018-14781](https://nvd.nist.gov/vuln/detail/CVE-2018-14781): “Medtronic insulin pump \[specific versions\] when paired with a remote controller and having the “easy bolus” and “remote bolus” options enabled (non-default), are vulnerable to a capture-replay attack. An attacker can … cause an insulin (bolus) delivery.” - - CVE-2017-9590: “The State Bank of Waterloo Mobile … app 3.0.2 … for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.” + - [CVE-2017-9590](https://nvd.nist.gov/vuln/detail/CVE-2017-9590): “The State Bank of Waterloo Mobile … app 3.0.2 … for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.” - - CVE-2017-3183: “Sage XRT Treasury, version 3, fails to properly restrict database access to authorized users, which may enable any authenticated user to gain full access to privileged database functions. Sage XRT Treasury is a business finance management application. …” + - [CVE-2017-3183](https://nvd.nist.gov/vuln/detail/CVE-2017-3183): “Sage XRT Treasury, version 3, fails to properly restrict database access to authorized users, which may enable any authenticated user to gain full access to privileged database functions. Sage XRT Treasury is a business finance management application. …” ### General Computing Cases - - CVE-2019-2691: “Vulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Security: Roles). Supported versions that are affected are 8.0.15 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to … complete DoS of MySQL Server.” + - [CVE-2019-2691](https://nvd.nist.gov/vuln/detail/CVE-2019-2691): “Vulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Security: Roles). Supported versions that are affected are 8.0.15 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to … complete DoS of MySQL Server.” - - CVE-2019-9042: “\[I\]n Sitemagic CMS v4.4… the user can upload a .php file to execute arbitrary code, as demonstrated by 404.php. This can only occur if the administrator neglects to set FileExtensionFilter and there are untrusted user accounts. …” + - [CVE-2019-9042](https://nvd.nist.gov/vuln/detail/CVE-2019-9042): “\[I\]n Sitemagic CMS v4.4… the user can upload a .php file to execute arbitrary code, as demonstrated by 404.php. This can only occur if the administrator neglects to set FileExtensionFilter and there are untrusted user accounts. …” - - CVE-2017-5638: “The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via crafted \[specific headers\], as exploited in the wild in March 2017…” + - [CVE-2017-5638](https://nvd.nist.gov/vuln/detail/CVE-2017-5638): “The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via crafted \[specific headers\], as exploited in the wild in March 2017…” ## Pilot Results -For each of the nine CVEs, six analysts rated the priority of the vulnerability as both a supplier and deployer. Table 13 summarizes the results by reporting the inter-rater agreement for each decision point. For all measures, agreement (*k*) is above zero, which is generally interpreted as some agreement among analysts. Below zero is interpreted as noise or discord. Closer to 1 indicates more or stronger agreement. +For each of the nine CVEs, six analysts rated the priority of the vulnerability as both a supplier and deployer. The table below summarizes the results by reporting the inter-rater agreement for each decision point. For all measures, agreement (*k*) is above zero, which is generally interpreted as some agreement among analysts. Below zero is interpreted as noise or discord. Closer to 1 indicates more or stronger agreement. How close *k* should be to 1 before agreement can be considered strong enough or reliable enough is a matter of some debate. The value certainly depends on the number of options among which analysts select. For those decision points with five options (mission and safety impact), agreement is lowest. Although portfolio value has a higher *k* than mission or safety impact, it may not actually have higher agreement because portfolio value only has two options. The results for portfolio value are nearly indistinguishable as far as level of statistical agreement from mission impact and safety impact. The statistical community does not have hard and fast rules for cut lines on adequate agreement. We treat *k* as a descriptive statistic rather than a test statistic. -Table 13 is encouraging, though not conclusive. *k*\<0 is a strong sign of discordance. Although it is unclear how close to 1 is success, *k*\<0 would be clear sign of failure. In some ways, these results may be undercounting the agreement for SSVC as presented. These results are for SSVC prior to the improvements documented in [Improvement Instigated by the Pilot](#improvements-instigated-by-the-pilot), which are implemented in SSVC version 1. On the other hand, the participant demographics may inflate the inter-rater agreement based on shared tacit understanding through the process of authorship. The one participant who was not an author surfaced two places where this was the case, but we expect the organizational homogeneity of the participants has inflated the agreement somewhat. The anecdotal feedback from vulnerability managers at several organizations (including VMware [@akbar2020ssvc] and McAfee) is about refinement and tweaks, not gross disagreement. Therefore, while further refinement is necessary, this evidence suggests the results have some transferability to other organizations and are not a total artifact of the participant organization demographics. +The following table is encouraging, though not conclusive. *k*\<0 is a strong sign of discordance. Although it is unclear how close to 1 is success, *k*\<0 would be clear sign of failure. In some ways, these results may be undercounting the agreement for SSVC as presented. These results are for SSVC prior to the improvements documented in [Improvement Instigated by the Pilot](#improvements-instigated-by-the-pilot), which are implemented in SSVC version 1. On the other hand, the participant demographics may inflate the inter-rater agreement based on shared tacit understanding through the process of authorship. The one participant who was not an author surfaced two places where this was the case, but we expect the organizational homogeneity of the participants has inflated the agreement somewhat. The anecdotal feedback from vulnerability managers at several organizations (including VMware [@akbar2020ssvc] and McAfee) is about refinement and tweaks, not gross disagreement. Therefore, while further refinement is necessary, this evidence suggests the results have some transferability to other organizations and are not a total artifact of the participant organization demographics. Table: Inter-Rater Agreement for Decision Points -| | Safety Impact | Exploitation | Technical Impact | Portfolio Value | Mission Impact| Exposure | Dev Result | Deployer Result | -| :--- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | -Fleiss’ *k* | 0.122 | 0.807 | 0.679 | 0.257 | 0.146 | 0.480 | 0.226 | 0.295 | -|Disagreement range | 2,4 | 1,2 | 1,1 | 1,1 | 2,4 | 1,2 | 1,3 | 2,3 | +| | Safety Impact | Exploitation | Technical Impact | Portfolio Value | Mission Impact | Exposure | Dev Result | Deployer Result | +|:-------------------|--------------:|-------------:|------------------:|----------------:|---------------:|---------:|-----------:|----------------:| +| Fleiss’ *k* | 0.122 | 0.807 | 0.679 | 0.257 | 0.146 | 0.480 | 0.226 | 0.295 | +| Disagreement range | 2,4 | 1,2 | 1,1 | 1,1 | 2,4 | 1,2 | 1,3 | 2,3 | For all decision points, the presumed goal is for *k* to be close or equal to 1. The statistics literature has identified some limited cases in which Fleiss’ k behaves strangely—for example it is lower than expected when raters are split between 2 of q ratings when q\>2 [@falotico2015fleiss]. This paradox may apply to the safety and mission impact values, in particular. The paradox would bite hardest if the rating for each vulnerability was clustered on the same two values, for example, minor and major. Falotico and Quatto’s proposed solution is to permute the columns, which is safe with unordered categorical data. Since the nine vulnerabilities do not have the same answers as each other (that is, the answers are not clustered on the same two values), we happen to avoid the worst of this paradox, but the results for safety impact and mission impact should be interpreted with some care. -This solution identifies another difficulty of Fleiss’ kappa, namely that it does not preserve any order; none and catastrophic are considered the same level of disagreement as none and minor. Table 13 displays a sense of the range of disagreement to complement this weakness. This value is the largest distance between rater selections on a single vulnerability out of the maximum possible distance. So, for safety impact, the most two raters disagreed was by two steps (none to major, minor to hazardous, or major to catastrophic) out of the four possible steps (none to catastrophic). The only values of *k* that are reliably comparable are those with the same number of options (that is, the same maximum distance). In other cases, closer to 1 is better, but how close is close enough to be considered “good” changes. In all but one case, if raters differed by two steps then there were raters who selected the central option between them. The exception was mission impact for CVE-201814781; it is unclear whether this discrepancy should be localized to a poor test scenario description, or to SSVC’s mission impact definition. Given it is an isolated occurrence, we expect the scenario description at least partly. +This solution identifies another difficulty of Fleiss’ kappa, namely that it does not preserve any order; none and catastrophic are considered the same level of disagreement as none and minor. The table above displays a sense of the range of disagreement to complement this weakness. This value is the largest distance between rater selections on a single vulnerability out of the maximum possible distance. So, for safety impact, the most two raters disagreed was by two steps (none to major, minor to hazardous, or major to catastrophic) out of the four possible steps (none to catastrophic). The only values of *k* that are reliably comparable are those with the same number of options (that is, the same maximum distance). In other cases, closer to 1 is better, but how close is close enough to be considered “good” changes. In all but one case, if raters differed by two steps then there were raters who selected the central option between them. The exception was mission impact for CVE-201814781; it is unclear whether this discrepancy should be localized to a poor test scenario description, or to SSVC’s mission impact definition. Given it is an isolated occurrence, we expect the scenario description at least partly. Nonetheless, *k* provides some way to measure improvement on this a conceptual engineering task. The pilot evaluation can be repeated, with more diverse groups of stakeholders after the descriptions have been refined by stakeholder input, to measure fit to this goal. For a standard to be reliably applied across different analyst backgrounds, skill sets, and cultures, a set of decision point descriptions should ideally achieve *k* of 1 for each item in multiple studies with diverse participants. Such a high level of agreement would be difficult to achieve, but it would ensure that when two analysts assign a priority with the system that they get the same answer. Such agreement is not the norm with CVSS currently [@allodi2018effect]. Table: SSVC pilot scores compared with the CVSS base scores for the vulnerabilities provided by NVD. -| CVE-ID | Representative SSVC decision values | SSVC recommendation (supplier, deployer) | NVD’s CVSS base score | -| :---------------- | :--------------------------------: | :--------------------- | :---------------------- | -| CVE-2014-0751 | E:N/T:T/U:L/S:H/X:C/M:C | (Sched, OOC) | 7.5 (High) (v2) | -| CVE-2015-1014 | E:N/T:T/U:L/S:J/X:S/M:F | (Sched, Sched) | 7.3 (High) (v3.0) | -| CVE-2015-5374 | E:A/T:P/U:L/S:H/X:C/M:F | (Immed, Immed) | 7.8 (High) (v2) | -| CVE-2017-3183 | E:N/T:T/U:E/S:M/X:C/M:C | (Sched, Sched) | 8.8 (High) (v3.0) | -| CVE-2017-5638 | E:A/T:T/U:S/S:M/X:U/M:C | (Immed, OOC) | 10.0 (Critical) (v3.0) | -| CVE-2017-9590 | E:P/T:T/U:E/S:M/X:U/M:D | (OOC, Sched) | 5.9 (Medium) (v3.0) | -| CVE-2018-14781 | E:P/T:P/U:L/S:H/X:C/M:F | (OOC, OOC) | 5.3 (Medium) (v3.0) | -| CVE-2019-2691 | E:N/T:P/U:E/S:M/X:C/M:C | (Sched, Sched) | 4.9 (Medium) (v3.0) | -| CVE-2019-9042 | E:A/T:T/U:L/S:N/X:C/M:C | (OOC, Sched) | 7.2 (High) (v3.0) | +| CVE-ID | Representative SSVC decision values | SSVC recommendation (supplier, deployer) | NVD’s CVSS base score | +|:------------------------------------------------------------------|:------------------------------------:|:------------------------------------------|:-----------------------| +| [CVE-2014-0751](https://nvd.nist.gov/vuln/detail/CVE-2014-0751) | E:N/T:T/U:L/S:H/X:C/M:C | (Sched, OOC) | 7.5 (High) (v2) | +| [CVE-2015-1014](https://nvd.nist.gov/vuln/detail/CVE-2015-1014) | E:N/T:T/U:L/S:J/X:S/M:F | (Sched, Sched) | 7.3 (High) (v3.0) | +| [CVE-2015-5374](https://nvd.nist.gov/vuln/detail/CVE-2015-5374) | E:A/T:P/U:L/S:H/X:C/M:F | (Immed, Immed) | 7.8 (High) (v2) | +| [CVE-2017-3183](https://nvd.nist.gov/vuln/detail/CVE-2017-3183) | E:N/T:T/U:E/S:M/X:C/M:C | (Sched, Sched) | 8.8 (High) (v3.0) | +| [CVE-2017-5638](https://nvd.nist.gov/vuln/detail/CVE-2017-5638) | E:A/T:T/U:S/S:M/X:U/M:C | (Immed, OOC) | 10.0 (Critical) (v3.0) | +| [CVE-2017-9590](https://nvd.nist.gov/vuln/detail/CVE-2017-9590) | E:P/T:T/U:E/S:M/X:U/M:D | (OOC, Sched) | 5.9 (Medium) (v3.0) | +| [CVE-2018-14781](https://nvd.nist.gov/vuln/detail/CVE-2018-14781) | E:P/T:P/U:L/S:H/X:C/M:F | (OOC, OOC) | 5.3 (Medium) (v3.0) | +| [CVE-2019-2691](https://nvd.nist.gov/vuln/detail/CVE-2019-2691) | E:N/T:P/U:E/S:M/X:C/M:C | (Sched, Sched) | 4.9 (Medium) (v3.0) | +| [CVE-2019-9042](https://nvd.nist.gov/vuln/detail/CVE-2019-9042) | E:A/T:T/U:L/S:N/X:C/M:C | (OOC, Sched) | 7.2 (High) (v3.0) | -Table 14 presents the mode decision point value for each vulnerability tested, as well as the recommendation that would result from that set based on the recommended decision trees in SSVC version 1. The comparison with the NVD’s CVSS base scores mostly confirms that SSVC is prioritizing based on different criteria, as designed. In particular, differences in the state of exploitation and safety impact are suggestive. +The table above presents the mode decision point value for each vulnerability tested, as well as the recommendation that would result from that set based on the recommended decision trees in SSVC version 1. The comparison with the NVD’s CVSS base scores mostly confirms that SSVC is prioritizing based on different criteria, as designed. In particular, differences in the state of exploitation and safety impact are suggestive. Based on these results, we made about ten changes, some bigger than others. We did not execute a new rater agreement experiment with the updated descriptions. The pilot results are encouraging, and we believe it is time to open up a wider community discussion. @@ -172,4 +183,4 @@ Some of these points left marks on other decision points. The decision point “ Three of the above decision points left no trace on the current system. “State of legal or regulatory obligations,” “cost of developing remediation,” and “patch distribution readiness” were dropped as either being too vaguely defined, too high level, or otherwise not within the scope of decisions by the defined stakeholders. The remaining decision point, “adversary’s strategic benefit of exploiting the vulnerability,” transmuted to a different sense of system value. In an attempt to be more concrete and not speculate about adversary motives, we considered a different sense of value: supplier portfolio value. -The only decision point that we have removed following the pilot is developer portfolio value. This notion of value was essentially an over-correction to the flaws identified in the “adversary’s strategic benefit of exploiting the vulnerability” decision point. “Supplier portfolio value” was defined as “the value of the affected component as a part of the developer’s product portfolio. Value is some combination of importance of a given piece of software, number of deployed instances of the software, and how many people rely on each. The developer may also include lifecycle stage (early development, stable release, decommissioning, etc.) as an aspect of value.” It had two possible values: low and high. As Table 13 demonstrates, there was relatively little agreement among the six analysts about how to evaluate this decision point. We replaced this sense of portfolio value with *Utility*, which combines *Value Density* and *Automatability*. +The only decision point that we have removed following the pilot is developer portfolio value. This notion of value was essentially an over-correction to the flaws identified in the “adversary’s strategic benefit of exploiting the vulnerability” decision point. “Supplier portfolio value” was defined as “the value of the affected component as a part of the developer’s product portfolio. Value is some combination of importance of a given piece of software, number of deployed instances of the software, and how many people rely on each. The developer may also include lifecycle stage (early development, stable release, decommissioning, etc.) as an aspect of value.” It had two possible values: low and high. As the inter-rater reliability table demonstrates, there was relatively little agreement among the six analysts about how to evaluate this decision point. We replaced this sense of portfolio value with *Utility*, which combines *Value Density* and *Automatability*. diff --git a/docs/topics/future_work.md b/docs/topics/future_work.md index eae393dc..61588546 100644 --- a/docs/topics/future_work.md +++ b/docs/topics/future_work.md @@ -9,7 +9,12 @@ Plans for future work focus on further requirements gathering, analysis of types The community should know what users of a vulnerability prioritization system want. To explore their needs, it is important to understand how people actually use CVSS and what they think it tells them. -In general, such empirical, grounded evidence about what practitioners and decision makers want from vulnerability scoring is lacking. We have based this paper’s methodology on multiple decades of professional experience and myriad informal conversations with practitioners. Such evidence is not a bad place to start, but it does not lend itself to examination and validation by others. The purpose of understanding practitioner expectations is to inform what a vulnerability-prioritization methodology should actually provide by matching it to what people want or expect. The method this future work should take is long-form, structured interviews. We do not expect anyone to have access to enough consumers of CVSS to get statistically valid results out of a short survey, nor to pilot a long survey. +In general, such empirical, grounded evidence about what practitioners and decision makers want from vulnerability scoring is lacking. +We have based SSVC’s methodology on multiple decades of professional experience and myriad informal conversations with practitioners. +Such evidence is not a bad place to start, but it does not lend itself to examination and validation by others. +The purpose of understanding practitioner expectations is to inform what a vulnerability-prioritization methodology should actually provide by matching it to what people need or expect. +The method this future work should take is long-form, structured interviews. +We do not expect anyone to have access to enough consumers of CVSS to get statistically valid results out of a short survey, nor to pilot a long survey. Coordinators in particular are likely to be heterogeneous. While the FIRST service frameworks for PSIRTs and CSIRTs differentiate two broad classes of coordinators, we have focused on CSIRTs here. diff --git a/docs/topics/information_sources.md b/docs/topics/information_sources.md index 11719941..35958607 100644 --- a/docs/topics/information_sources.md +++ b/docs/topics/information_sources.md @@ -37,6 +37,8 @@ Three prominent examples are CVSS impact base metrics, CWE, and CPE. ### CVSS and Technical Impact +{% include-markdown "../_includes/_cvss4_question.md" heading-offset=1 %} + [*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. @@ -44,7 +46,7 @@ If the CVSS version 3 value of “Scope” is “Changed,” then the impact met 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” . +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*](../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 @@ -74,7 +76,7 @@ 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](../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. +[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 sort of feed could support each of those decision points. A feed is plausible for both of these decision points. 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. @@ -82,6 +84,12 @@ While that is a broad analysis frame, it means that any community that shares a 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. +!!! note inline end "CVSS v4, Automatable, and Value Density" + + It is not coincidental that the CVSS v4 supplemental metrics include [Automatable](https://www.first.org/cvss/v4.0/specification-document#Automatable-AU) + (AU) and [Value Density](https://www.first.org/cvss/v4.0/specification-document#Value-Density-V) (V). + The SSVC team collaborated in the development of these metrics with the [FIRST CVSS Special Interest Group](https://www.first.org/cvss). + 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. diff --git a/docs/topics/items_with_same_priority.md b/docs/topics/items_with_same_priority.md index 62fbee1b..87641842 100644 --- a/docs/topics/items_with_same_priority.md +++ b/docs/topics/items_with_same_priority.md @@ -8,9 +8,11 @@ The priority is equivalent. !!! tip "This is not CVSS" This approach may feel uncomfortable since CVSS gives the appearance of a finer grained priority. - CVSS appears to say, + CVSS appears to say, + > Not just 4.0 to 6.9 is ‘medium’ severity, but 4.6 is more severe than 4.5. - However, CVSS is designed to be accurate only within +/- 0.5, + + However, CVSS v3.1 is designed to be accurate only within +/- 0.5, and, in practice, is scored with errors of around +/- 1.5 to 2.5 [@allodi2018effect, see Figure 1]. An error of this magnitude is enough to make all of the “normal” range from 4.0 to 6.9 equivalent, because diff --git a/docs/topics/related_systems.md b/docs/topics/related_systems.md index c16deaf8..7bcef98f 100644 --- a/docs/topics/related_systems.md +++ b/docs/topics/related_systems.md @@ -9,6 +9,8 @@ This section discusses the relationship between these various systems and SSVC. ## CVSS +{% include-markdown "../_includes/_cvss4_question.md" heading-offset=1 %} + CVSS version 3.1 has three metric groups: base, environmental, and temporal. The metrics in the base group are all required, and are the only required metrics. In connection with this design, CVSS base scores and base metrics are far and away the most commonly used and communicated. @@ -26,7 +28,7 @@ In these three examples, the modifications tend to add complexity to CVSS by add 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) +### 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](../reference/decision_points/automatable.md) decision point. @@ -46,7 +48,7 @@ Most notably the concept of vulnerability chaining is addressed in [Automatabili 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. -> Impact metrics (Base metric group) +### Impact metrics (Base metric group) The metrics in this group are Confidentiality, Integrity, and Availability. There is also a loosely associated Scope metric. @@ -60,13 +62,13 @@ The impact of exploitation of the vulnerable component on other components is co 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.md) section. -> Temporal metric groups +### Temporal metric groups The temporal metric group primarily contains the Exploit Code Maturity metric. 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 +### Environmental metric group The environmental metric group allows a consumer of a CVSS base score to change it based on their environment. CVSS needs this functionality because the organizations that produce CVSS scores tend to be what SSVC calls **suppliers** and consumers of CVSS scores are what SSVC calls **deployers**. diff --git a/docs/topics/worked_example.md b/docs/topics/worked_example.md index 4ecb95d7..857a1892 100644 --- a/docs/topics/worked_example.md +++ b/docs/topics/worked_example.md @@ -1,7 +1,7 @@ # Worked Example -As an example, we will evaluate CVE-2018-14781 step by step from the deployer point of view. +As an example, we will evaluate [CVE-2018-14781](https://nvd.nist.gov/vuln/detail/CVE-2018-14781) step by step from the deployer point of view. The scenario here is that used for the pilot study. This example uses the SSVC version 1 deployer decision tree. @@ -43,9 +43,11 @@ 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*](../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 -is complex, with many MEFs. +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 is complex, with many Mission Essential Functions (MEFs). However, even from this abstract, it seems clear that “do no harm” is at risk due to this vulnerability. A mission essential function to that mission is each of the various medical devices works as expected, or at least if a device fails, it cannot actively be used to inflict harm. @@ -58,7 +60,7 @@ Therefore, we select [*MEF failure*](../reference/decision_points/mission_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*](../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. +Conducting further studies with the more recent versions of the Deployer decision model remains an area of future work. In the pilot study, this information is conveyed as follows: !!! info "Use of the cyber-physical system" diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md index de1f96eb..ba3c6f09 100644 --- a/docs/tutorials/index.md +++ b/docs/tutorials/index.md @@ -1,6 +1,23 @@ # Learning SSVC -{== todo add intro ==} +SSVC stands for Stakeholder-Specific Vulnerability Categorization. +It is a methodology for prioritizing vulnerabilities based on the needs of the stakeholders involved in the vulnerability management process. +SSVC is designed to be used by any stakeholder in the vulnerability management process, including patch suppliers, patch deployers, coordinators, and others. +One of SSVC's key features is that it is intended to be customized to the needs of the organization using it. +In the [HowTo](../howto/index.md) section, we provide a set of decision models that can be used as a starting point, +but we expect that organizations will need to modify these models to fit their specific needs. +An introduction to how we think about SSVC can be found in the [Understanding SSVC](../topics/index.md) section. +For technical reference, including a list of decision points, see [Reference](../reference/index.md). + +!!! info "SSVC in a Nutshell" + + SSVC is built around the concept of a **Decision Model** that takes a set of input **Decision Points** and + applies a **Policy** to produce a set of output **Outcomes**. + The **Decision Points** are the factors that influence the decision, and the **Outcomes** are the possible results of the decision. + Both **Decision Points** and **Outcomes** are defined as ordered sets of enumerated values. + The **Policy** is a mapping from each combination of decision point values to the set of outcome values. + One of SSVC's goals is to provide a methodology to develop risk-informed guidance at a human scale, while enabling + data-driven decision-making. !!! tip "SSVC Calculator" @@ -8,8 +25,32 @@ The decisions modeled in the calculator are based on the [Supplier](../howto/supplier_tree.md), [Deployer](../howto/deployer_tree.md), and [Coordinator](../howto/coordination_intro.md) decision models. +SSVC can be used in conjunction with other tools and methodologies to help prioritize vulnerability response. + +!!! example "CVSS and SSVC" + + The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of + software security vulnerabilities. + CVSS assigns technical severity scores to vulnerabilities, and many organizations use this score to inform their + vulnerability management process. + In SSVC, we took a different approach with our stakeholder-specific model, although the information contained in a + CVSS vector can be applied to SSVC decision models. + For example, the [Technical Impact](../reference/decision_points/technical_impact.md) decision point in + the [Supplier](../howto/supplier_tree.md) decision model can be informed by the CVSS vector. + +!!! example "EPSS and SSVC" + + The Exploit Prediction Scoring System (EPSS) provides information regarding the likelihood of a vulnerability being exploited in the wild. + This information can be used to inform the [Exploitation](../reference/decision_points/exploitation.md) decision point in the + [Supplier](../howto/supplier_tree.md), [Deployer](../howto/deployer_tree.md), and [Coordinator Publication](../howto/publication_decision.md) decision models. + + + + ## Videos +Provided below are videos that provide an overview of SSVC and the implementation of decision models. + | Source | Video | | ------ |----------------------------------------------------------------------------------------------------------------------------------| | SEI Podcast Series | [A Stakeholder-Specific Approach to Vulnerability Management](https://youtu.be/wbUTizBaXA0) | @@ -23,6 +64,8 @@ ## Other Content +We've collected a list of articles and blog posts that provide additional information about SSVC. + | Source | Link | |- -------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | SEI | [Prioritizing Vulnerability Response with a Stakeholder-Specific Vulnerability Categorization](https://insights.sei.cmu.edu/blog/prioritizing-vulnerability-response-with-a-stakeholder-specific-vulnerability-categorization/) | From 0213b6d257a2eaf35629577e9e72616798000f08 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Tue, 5 Mar 2024 12:01:04 -0500 Subject: [PATCH 104/113] Update references in Risk Tolerance (#525) * update references in risk tolerance also adjust format/spacing * typo fix * typo fix --- docs/topics/risk_tolerance_and_priority.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/docs/topics/risk_tolerance_and_priority.md b/docs/topics/risk_tolerance_and_priority.md index aa0e484d..631be2dc 100644 --- a/docs/topics/risk_tolerance_and_priority.md +++ b/docs/topics/risk_tolerance_and_priority.md @@ -1,14 +1,15 @@ # Risk Tolerance and Response Priority SSVC enables stakeholders to balance and manage their risks themselves. -We follow the risk management vocabulary from [@ISO73] and define risk as “effect of uncertainty on objectives;” -see [@ISO73] for notes on the terms in the definition. +We follow the risk management vocabulary from [ISO 31073:2022(en) +Risk management — Vocabulary](https://www.iso.org/obp/ui/#iso:std:iso:31073:ed-1:v1:en) and define risk as “effect of uncertainty on objectives;” +see the original document for notes on the terms in the definition. A successful vulnerability management practice must balance at least two risks: -!!! tip inline end "Contexualizing Risk" - - To place these risks in context, we follow the SEI's Taxonomy of Operational Cyber Security Risks [@cebula2010taxonomy]. +!!! tip inline end "Contextualizing Risk" + To place these risks in context, we follow the SEI's + [Taxonomy of Operational Cyber Security Risks](https://insights.sei.cmu.edu/library/a-taxonomy-of-operational-cyber-security-risks/). **Change risk** can be characterized as a combination of Class 2 and/or Class 3 risks. - Class 2: Systems and Technology Failures includes hardware, software, and systems risks. @@ -26,6 +27,9 @@ In developing the decision trees in this document, we had in mind stakeholders w We therefore remind our readers that the labels on the trees (defer, immediate, etc.) can and should be customized to suit the needs of individual stakeholders wherever necessary and appropriate. + +--- + !!! example "Risk Tolerance Influences Response Priority" - An organization with a high aversion to change risk might choose to accept more vulnerability risk by From 27f9bcef2d53e9916b1018e22ec6804adfa54b5d Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Tue, 5 Mar 2024 12:30:14 -0500 Subject: [PATCH 105/113] Fix latex rendering on page load (#527) --- docs/javascripts/mathjax.js | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/javascripts/mathjax.js b/docs/javascripts/mathjax.js index 06dbf38b..7e48906a 100644 --- a/docs/javascripts/mathjax.js +++ b/docs/javascripts/mathjax.js @@ -12,5 +12,8 @@ window.MathJax = { }; document$.subscribe(() => { + MathJax.startup.output.clearCache() + MathJax.typesetClear() + MathJax.texReset() MathJax.typesetPromise() }) From eb098214d827e09c290b1334ad46c7c1b61ea64e Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Tue, 5 Mar 2024 13:05:32 -0500 Subject: [PATCH 106/113] Inline refs (#526) * inline reference link * replace numbered table reference * formatting * inline refs --- docs/topics/asset_management.md | 2 +- docs/topics/evaluation_of_draft_trees.md | 34 ++++++++++-------------- docs/topics/related_systems.md | 4 +-- docs/topics/worked_example.md | 2 +- 4 files changed, 18 insertions(+), 24 deletions(-) diff --git a/docs/topics/asset_management.md b/docs/topics/asset_management.md index 95279f87..a86cddaa 100644 --- a/docs/topics/asset_management.md +++ b/docs/topics/asset_management.md @@ -31,7 +31,7 @@ Once the organization remediates or mitigates all the high-priority vulnerabilit Asset management and risk management also drive some of the up-front work an organization would need to do to gather some of the necessary information. 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]. +The organization can pick its choice of tools; there are [hundreds of asset management tools on the market](https://www.capterra.com/it-asset-management-software/). Emerging standards like the [Software Bill of Materials](https://www.cisa.gov/sbom) (SBOM) 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](../reference/decision_points/mission_impact.md)) diff --git a/docs/topics/evaluation_of_draft_trees.md b/docs/topics/evaluation_of_draft_trees.md index 4bde0c5c..d4ea0bc3 100644 --- a/docs/topics/evaluation_of_draft_trees.md +++ b/docs/topics/evaluation_of_draft_trees.md @@ -91,29 +91,23 @@ Third, the pilot provides a proof of concept method and metric that any vulnerab The vulnerabilities used as case studies are as follows. All quotes are from the [National Vulnerability Database (NVD)](https://nvd.nist.gov/) and are illustrative of the vulnerability; however, during the study each vulnerability was evaluated according to information analogous to that in the scenario table above. -### Safety-Critical Cases +!!! example "Safety-Critical Cases" - - [CVE-2015-5374](https://nvd.nist.gov/vuln/detail/CVE-2015-5374): “Vulnerability … in \[Siemens\] Firmware variant PROFINET IO for EN100 Ethernet module… Specially crafted packets sent to port 50000/UDP could cause a denial-of-service of the affected device…” + - [CVE-2015-5374](https://nvd.nist.gov/vuln/detail/CVE-2015-5374): “Vulnerability … in \[Siemens\] Firmware variant PROFINET IO for EN100 Ethernet module… Specially crafted packets sent to port 50000/UDP could cause a denial-of-service of the affected device…” + - [CVE-2014-0751](https://nvd.nist.gov/vuln/detail/CVE-2014-0751): “Directory traversal vulnerability in … GE Intelligent Platforms Proficy HMI/SCADA - CIMPLICITY before 8.2 SIM 24, and Proficy Process Systems with CIMPLICITY, allows remote attackers to execute arbitrary code via a crafted message to TCP port 10212, aka ZDI-CAN-1623.” + - [CVE-2015-1014](https://nvd.nist.gov/vuln/detail/CVE-2015-1014): “A successful exploit of these vulnerabilities requires the local user to load a crafted DLL file in the system directory on servers running Schneider Electric OFS v3.5 with version v7.40 of SCADA Expert Vijeo Citect/CitectSCADA, OFS v3.5 with version v7.30 of Vijeo Citect/CitectSCADA, and OFS v3.5 with version v7.20 of Vijeo Citect/CitectSCADA. If the application attempts to open that file, the application could crash or allow the attacker to execute arbitrary code.” - - [CVE-2014-0751](https://nvd.nist.gov/vuln/detail/CVE-2014-0751): “Directory traversal vulnerability in … GE Intelligent Platforms Proficy HMI/SCADA - CIMPLICITY before 8.2 SIM 24, and Proficy Process Systems with CIMPLICITY, allows remote attackers to execute arbitrary code via a crafted message to TCP port 10212, aka ZDI-CAN-1623.” +!!! example "Regulated Systems Cases" - - [CVE-2015-1014](https://nvd.nist.gov/vuln/detail/CVE-2015-1014): “A successful exploit of these vulnerabilities requires the local user to load a crafted DLL file in the system directory on servers running Schneider Electric OFS v3.5 with version v7.40 of SCADA Expert Vijeo Citect/CitectSCADA, OFS v3.5 with version v7.30 of Vijeo Citect/CitectSCADA, and OFS v3.5 with version v7.20 of Vijeo Citect/CitectSCADA. If the application attempts to open that file, the application could crash or allow the attacker to execute arbitrary code.” + - [CVE-2018-14781](https://nvd.nist.gov/vuln/detail/CVE-2018-14781): “Medtronic insulin pump \[specific versions\] when paired with a remote controller and having the “easy bolus” and “remote bolus” options enabled (non-default), are vulnerable to a capture-replay attack. An attacker can … cause an insulin (bolus) delivery.” + - [CVE-2017-9590](https://nvd.nist.gov/vuln/detail/CVE-2017-9590): “The State Bank of Waterloo Mobile … app 3.0.2 … for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.” + - [CVE-2017-3183](https://nvd.nist.gov/vuln/detail/CVE-2017-3183): “Sage XRT Treasury, version 3, fails to properly restrict database access to authorized users, which may enable any authenticated user to gain full access to privileged database functions. Sage XRT Treasury is a business finance management application. …” -### Regulated Systems Cases +!!! example "General Computing Cases" - - [CVE-2018-14781](https://nvd.nist.gov/vuln/detail/CVE-2018-14781): “Medtronic insulin pump \[specific versions\] when paired with a remote controller and having the “easy bolus” and “remote bolus” options enabled (non-default), are vulnerable to a capture-replay attack. An attacker can … cause an insulin (bolus) delivery.” - - - [CVE-2017-9590](https://nvd.nist.gov/vuln/detail/CVE-2017-9590): “The State Bank of Waterloo Mobile … app 3.0.2 … for iOS does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.” - - - [CVE-2017-3183](https://nvd.nist.gov/vuln/detail/CVE-2017-3183): “Sage XRT Treasury, version 3, fails to properly restrict database access to authorized users, which may enable any authenticated user to gain full access to privileged database functions. Sage XRT Treasury is a business finance management application. …” - -### General Computing Cases - - - [CVE-2019-2691](https://nvd.nist.gov/vuln/detail/CVE-2019-2691): “Vulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Security: Roles). Supported versions that are affected are 8.0.15 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to … complete DoS of MySQL Server.” - - - [CVE-2019-9042](https://nvd.nist.gov/vuln/detail/CVE-2019-9042): “\[I\]n Sitemagic CMS v4.4… the user can upload a .php file to execute arbitrary code, as demonstrated by 404.php. This can only occur if the administrator neglects to set FileExtensionFilter and there are untrusted user accounts. …” - - - [CVE-2017-5638](https://nvd.nist.gov/vuln/detail/CVE-2017-5638): “The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via crafted \[specific headers\], as exploited in the wild in March 2017…” + - [CVE-2019-2691](https://nvd.nist.gov/vuln/detail/CVE-2019-2691): “Vulnerability in the MySQL Server component of Oracle MySQL (subcomponent: Server: Security: Roles). Supported versions that are affected are 8.0.15 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to … complete DoS of MySQL Server.” + - [CVE-2019-9042](https://nvd.nist.gov/vuln/detail/CVE-2019-9042): “\[I\]n Sitemagic CMS v4.4… the user can upload a .php file to execute arbitrary code, as demonstrated by 404.php. This can only occur if the administrator neglects to set FileExtensionFilter and there are untrusted user accounts. …” + - [CVE-2017-5638](https://nvd.nist.gov/vuln/detail/CVE-2017-5638): “The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via crafted \[specific headers\], as exploited in the wild in March 2017…” ## Pilot Results @@ -121,7 +115,7 @@ For each of the nine CVEs, six analysts rated the priority of the vulnerability How close *k* should be to 1 before agreement can be considered strong enough or reliable enough is a matter of some debate. The value certainly depends on the number of options among which analysts select. For those decision points with five options (mission and safety impact), agreement is lowest. Although portfolio value has a higher *k* than mission or safety impact, it may not actually have higher agreement because portfolio value only has two options. The results for portfolio value are nearly indistinguishable as far as level of statistical agreement from mission impact and safety impact. The statistical community does not have hard and fast rules for cut lines on adequate agreement. We treat *k* as a descriptive statistic rather than a test statistic. -The following table is encouraging, though not conclusive. *k*\<0 is a strong sign of discordance. Although it is unclear how close to 1 is success, *k*\<0 would be clear sign of failure. In some ways, these results may be undercounting the agreement for SSVC as presented. These results are for SSVC prior to the improvements documented in [Improvement Instigated by the Pilot](#improvements-instigated-by-the-pilot), which are implemented in SSVC version 1. On the other hand, the participant demographics may inflate the inter-rater agreement based on shared tacit understanding through the process of authorship. The one participant who was not an author surfaced two places where this was the case, but we expect the organizational homogeneity of the participants has inflated the agreement somewhat. The anecdotal feedback from vulnerability managers at several organizations (including VMware [@akbar2020ssvc] and McAfee) is about refinement and tweaks, not gross disagreement. Therefore, while further refinement is necessary, this evidence suggests the results have some transferability to other organizations and are not a total artifact of the participant organization demographics. +The following table is encouraging, though not conclusive. *k*<0 is a strong sign of discordance. Although it is unclear how close to 1 is success, *k*<0 would be clear sign of failure. In some ways, these results may be undercounting the agreement for SSVC as presented. These results are for SSVC prior to the improvements documented in [Improvement Instigated by the Pilot](#improvements-instigated-by-the-pilot), which are implemented in SSVC version 1. On the other hand, the participant demographics may inflate the inter-rater agreement based on shared tacit understanding through the process of authorship. The one participant who was not an author surfaced two places where this was the case, but we expect the organizational homogeneity of the participants has inflated the agreement somewhat. The anecdotal feedback from vulnerability managers at several organizations (including VMware [@akbar2020ssvc] and McAfee) is about refinement and tweaks, not gross disagreement. Therefore, while further refinement is necessary, this evidence suggests the results have some transferability to other organizations and are not a total artifact of the participant organization demographics. Table: Inter-Rater Agreement for Decision Points @@ -132,7 +126,7 @@ Table: Inter-Rater Agreement for Decision Points For all decision points, the presumed goal is for *k* to be close or equal to 1. The statistics literature has identified some limited cases in which Fleiss’ k behaves strangely—for example it is lower than expected when raters are split between 2 of q ratings when q\>2 [@falotico2015fleiss]. This paradox may apply to the safety and mission impact values, in particular. The paradox would bite hardest if the rating for each vulnerability was clustered on the same two values, for example, minor and major. Falotico and Quatto’s proposed solution is to permute the columns, which is safe with unordered categorical data. Since the nine vulnerabilities do not have the same answers as each other (that is, the answers are not clustered on the same two values), we happen to avoid the worst of this paradox, but the results for safety impact and mission impact should be interpreted with some care. -This solution identifies another difficulty of Fleiss’ kappa, namely that it does not preserve any order; none and catastrophic are considered the same level of disagreement as none and minor. The table above displays a sense of the range of disagreement to complement this weakness. This value is the largest distance between rater selections on a single vulnerability out of the maximum possible distance. So, for safety impact, the most two raters disagreed was by two steps (none to major, minor to hazardous, or major to catastrophic) out of the four possible steps (none to catastrophic). The only values of *k* that are reliably comparable are those with the same number of options (that is, the same maximum distance). In other cases, closer to 1 is better, but how close is close enough to be considered “good” changes. In all but one case, if raters differed by two steps then there were raters who selected the central option between them. The exception was mission impact for CVE-201814781; it is unclear whether this discrepancy should be localized to a poor test scenario description, or to SSVC’s mission impact definition. Given it is an isolated occurrence, we expect the scenario description at least partly. +This solution identifies another difficulty of Fleiss’ kappa, namely that it does not preserve any order; none and catastrophic are considered the same level of disagreement as none and minor. The table above displays a sense of the range of disagreement to complement this weakness. This value is the largest distance between rater selections on a single vulnerability out of the maximum possible distance. So, for safety impact, the most two raters disagreed was by two steps (none to major, minor to hazardous, or major to catastrophic) out of the four possible steps (none to catastrophic). The only values of *k* that are reliably comparable are those with the same number of options (that is, the same maximum distance). In other cases, closer to 1 is better, but how close is close enough to be considered “good” changes. In all but one case, if raters differed by two steps then there were raters who selected the central option between them. The exception was mission impact for [CVE-2018-14781](https://nvd.nist.gov/vuln/detail/CVE-2018-14781); it is unclear whether this discrepancy should be localized to a poor test scenario description, or to SSVC’s mission impact definition. Given it is an isolated occurrence, we expect the scenario description at least partly. Nonetheless, *k* provides some way to measure improvement on this a conceptual engineering task. The pilot evaluation can be repeated, with more diverse groups of stakeholders after the descriptions have been refined by stakeholder input, to measure fit to this goal. For a standard to be reliably applied across different analyst backgrounds, skill sets, and cultures, a set of decision point descriptions should ideally achieve *k* of 1 for each item in multiple studies with diverse participants. Such a high level of agreement would be difficult to achieve, but it would ensure that when two analysts assign a priority with the system that they get the same answer. Such agreement is not the norm with CVSS currently [@allodi2018effect]. diff --git a/docs/topics/related_systems.md b/docs/topics/related_systems.md index 7bcef98f..4a4ed6ee 100644 --- a/docs/topics/related_systems.md +++ b/docs/topics/related_systems.md @@ -2,8 +2,8 @@ # Related Vulnerability Management Systems There are several other bodies of work that are used in practice to assist vulnerability managers in making decisions. -Three relevant systems are CVSS [@cvss_v3-1], EPSS [@jacobs2021epss], and Tenable's Vulnerability Priority Rating ([VPR](https://www.tenable.com/blog/what-is-vpr-and-how-is-it-different-from-cvss)). -There are other systems derived from CVSS, such as RVSS for robots [@vilches2018towards] and MITRE's effort to adapt CVSS to medical devices [@mitre2019medical]. +Three relevant systems are [CVSS](https://www.first.org/cvss/v3.1/specification-document), [EPSS](https://dl.acm.org/doi/10.1145/3436242), and Tenable's Vulnerability Priority Rating ([VPR](https://www.tenable.com/blog/what-is-vpr-and-how-is-it-different-from-cvss)). +There are other systems derived from CVSS, such as RVSS for robots [@vilches2018towards] and MITRE's [Rubric for Applying CVSS to Medical Devices](https://www.mitre.org/news-insights/publication/rubric-applying-cvss-medical-devices). There are also other nascent efforts to automate aspects of the decision making process, such as [vPrioritizer](https://github.com/varchashva/vPrioritizer). This section discusses the relationship between these various systems and SSVC. diff --git a/docs/topics/worked_example.md b/docs/topics/worked_example.md index 857a1892..21542a34 100644 --- a/docs/topics/worked_example.md +++ b/docs/topics/worked_example.md @@ -81,7 +81,7 @@ Depending on the details of the hospital’s contingency plans and its monitorin 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*](../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*](../reference/decision_points/safety_impact.md) in Table 13. +[*Safety Impact*](../reference/decision_points/safety_impact.md) in our evaluation of [inter-rater agreement](evaluation_of_draft_trees.md). For the purposes of this example, imagine that after gathering that information, the monitoring situation is adequate, 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 From d09330154729a7f0ab55b71bc4635be2e73db5f9 Mon Sep 17 00:00:00 2001 From: j--- Date: Tue, 5 Mar 2024 13:39:41 -0500 Subject: [PATCH 107/113] draft of update for cvss v4 (#528) * draft of update for cvss v4 * add links, formatting, copy edit * break up list paragraph --------- Co-authored-by: Allen D. Householder --- docs/topics/information_sources.md | 55 +++++++++++++++++++++++++----- 1 file changed, 46 insertions(+), 9 deletions(-) diff --git a/docs/topics/information_sources.md b/docs/topics/information_sources.md index 35958607..2e080f6f 100644 --- a/docs/topics/information_sources.md +++ b/docs/topics/information_sources.md @@ -37,17 +37,54 @@ Three prominent examples are CVSS impact base metrics, CWE, and CPE. ### CVSS and Technical Impact -{% include-markdown "../_includes/_cvss4_question.md" heading-offset=1 %} - [*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. +The interpretation is different for CVSS version 3 than version 4. + +!!! tip "Mapping CVSS v4 to Technical Impact" + + For CVSS v4, the [impact metric group](https://www.first.org/cvss/v4.0/specification-document#Impact-Metrics) can be + directly mapped to [*Technical Impact*](../reference/decision_points/technical_impact.md). + Stakeholders can define their own mapping, but the recommended mapping between CVSS v4 metric values and [*Technical Impact*](../reference/decision_points/technical_impact.md) is + + | Confidentiality
(VC) | Integrity
(VI) | Availability
(VA) | [*Technical Impact*](../reference/decision_points/technical_impact.md) | + |:--------------------:|---------------------|--------------------|------------------------------------------------------------------------| + | High (H) | High (H) | *any* | Total | + | High (H) | Low (L) or None (N) | *any* | Partial | + | Low (L) or None (N) | High (H) | *any* | Partial | + + That is, if the vulnerability leads to a high impact on the confidentiality and integrity of the vulnerable system, then that is equivalent to total technical impact on the system. + +The following considerations are accounted for in this recommendation. + +1. A denial of service condition is modeled as a *partial* [*Technical Impact*](../reference/decision_points/technical_impact.md). +Therefore, a high availability impact to the vulnerable system should not be mapped to *total* [*Technical Impact*](../reference/decision_points/technical_impact.md) on its own. +2. There may be situations in which a high confidentiality impact is sufficient for total technical impact; for example, disclosure of the root or administrative password for the system leads to total technical control of the system. +So this suggested mapping is a useful heuristic, but there may be exceptions, depending on exactly what the CVSS v4 metric value assignment norms are and become for these situations. +3. While the Subsequent System impact metric group in CVSS v4 is useful, those concepts are not captured by [*Technical Impact*](../reference/decision_points/technical_impact.md). +Subsequent System impacts are captured, albeit in different framings, by decision points such as [*Situated Safety Impact*](../reference/decision_points/safety_impact.md), [*Mission Impact*](../reference/decision_points/mission_impact.md), and [*Value Density*](../reference/decision_points/value_density.md). +There is not a direct mapping between the subsequent system impact metric group and these decision points, except in the case of [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md) and the CVSS v4 environmental metrics for Safety Impact in the subsequent system metric group. +In that case, both definitions map back to the same safety impact standard for definitions (IEC 61508) and so are easily mapped to each other. + +#### CVSS v3 and Technical Impact + +For CVSS v3, the impact metric group cannot be directly mapped to [*Technical Impact*](../reference/decision_points/technical_impact.md) because of the [Scope metric](https://www.first.org/cvss/v3.1/specification-document#2-2-Scope-S). [*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*](../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*](../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. +If the CVSS version 3 value of “Scope” is “Unchanged,” then the recommendation is the same as that for CVSS v4, above, as the impact metric group is information exclusively about the vulnerable system. +If the CVSS version 3 value of “Scope” is “Changed,” then the impact metrics may be about either the vulnerable system or the subsequent systems, based on whichever makes the final score higher. +Since [*Technical Impact*](../reference/decision_points/technical_impact.md) is based only on the vulnerable system impacts, if "Scope" is "Changed" then the ambiguity between vulnerable and subsequent system impacts is not documented in the vector string. +This ambiguity makes it impossible to cleanly map the [*Technical Impact*](../reference/decision_points/technical_impact.md) value in this case. + +!!! tip "Mapping CVSS v3 to Technical Impact" + + Summarizing the discussion above, the mapping between CVSS v3 and [*Technical Impact*](../reference/decision_points/technical_impact.md) is + + | CVSS Scope | Confidentiality
(C) | Integrity
(I) | Availability
(A) | [*Technical Impact*](../reference/decision_points/technical_impact.md) | + |:----------:|:-----------------------:|:------------------:|:---------------------:|------------------------------------------------------------------------| + | Unchanged | High (H) | High (H) | *any* | Total | + | Unchanged | High (H) | Low (L) or None (N)| *any* | Partial | + | Unchanged | Low (L) or None (N) | High (H) | *any* | Partial | + | Changed | *any* | *any* | *any* | (ambiguous) | + ### CWE and Exploitation From 606accd5440eda5978f9b18f4ddc00540f2a99df Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 8 Mar 2024 09:34:44 -0500 Subject: [PATCH 108/113] Update README.md (#518) --- README.md | 70 +- draft/ssvc.html | 5083 --------------------- draft/ssvc.pdf => pdfs/ssvc_2_1_draft.pdf | Bin 3 files changed, 50 insertions(+), 5103 deletions(-) delete mode 100644 draft/ssvc.html rename draft/ssvc.pdf => pdfs/ssvc_2_1_draft.pdf (100%) diff --git a/README.md b/README.md index 6838e477..1b0cf593 100644 --- a/README.md +++ b/README.md @@ -5,17 +5,30 @@ The Stakeholder-specific Vulnerability Categorization (SSVC) is a system for prioritizing actions during vulnerability management. SSVC aims to avoid one-size-fits-all solutions in favor of a modular decision-making system with clearly defined and tested parts that vulnerability managers can select and use as appropriate to their context. -# What's here +--- SSVC is mostly conceptual tools for vulnerability management. These conceptual tools (how to make decisions, what should go into a decision, how to document and communicate decisions clearly, etc.) are described here. +**Note:** This repository contains the _content_ for the main SSVC documentation hosted at + +## [https://certcc.github.io/SSVC/](https://certcc.github.io/SSVC/) + +- If you are just looking for SSVC documentation, you should go there. +- If you are interested in contributing to the SSVC documentation, you are in the right place. + +--- + + +# What's here + +Here's a quick overview of the main directories and files in this repository. + ## `/docs/*` Raw markdown and graphics files used to build the SSVC documentation website. See [`project_docs/README.md`](project_docs/README.md) for more info. - ### `/docs/ssvc-calc` Directory with SSVC calculator using D3 graph. @@ -23,39 +36,53 @@ See [`ssvc-calc/README.md`](docs/ssvc-calc/README.md) for more info. A demo version of `ssvc-calc` can be found at https://certcc.github.io/SSVC/ssvc-calc/ +## `/pdfs/*` -## `/draft/*` +Static versions of previously issued PDF reports are stored in this directory. -Generated drafts of reports. -Up through SSVC v2.1.1, these were recent versions of the main document in both `pdf` and `html` formats. +## `/data/*` -With the recent conversion from the SSVC documentation from `pdf`-document orientation to a website orientation, -we are no longer generating `pdf` versions of the main document. +The data folder contains detailed data files that define suggested prioritization results based on each combination of information on a vulnerability work item. -## `/pdfs/*.pdf` +There are both `.csv` and `.json` files in this directory. -Static versions of previously issued reports are stored in this directory. +### `/data/csvs/*` -## `/data/*.csv` +The `.csv` files are the primary data files used by the `ssvc.py` module. -The data folder contains detailed data files that define suggested prioritization results based on each combination of information on a vulnerability work item. -Also included in data are the lookup tables as csv files which `ssvc.py` reads in. +Also included in data are the lookup tables as csv files which `ssvc_v2.py` reads in. These files define one row per possible path through the trees as described in the documentation. -Customizing the "outcome" column in this csv is the primary recommended way that stakehodlers might adapt SSVC to their environment. +Customizing the "outcome" column in this csv is the primary recommended way that stakeholders might adapt SSVC to their environment. + +### `/data/json/*` + +These json files are generated examples from the python `ssvc` module. + +### `/data/schema/*` and `/data/schema_examples/*` + +These files are used by the `ssvc-calc` module. ## `/src/*` -The tools in the `src` folder provide an interface to work with these data files. +This directory holds helper scripts that can make managing or using SSVC easier. + +### `/src/ssvc/*` -### `src/ssvc.py` +The `ssvc` python module provides tools to work with decision points, decision point groups, and outcomes. +These modules are used to generate documentation for various [Decision Points](https://certcc.github.io/SSVC/reference/decsion_points/) -A basic Python module for interacting with the SSVC trees. `ssvc.py` has +Documentation for the `ssvc` module can be found at [https://certcc.github.io/SSVC/reference/code/](https://certcc.github.io/SSVC/reference/code/) + +### `src/ssvc_v2.py` + +A basic Python module for interacting with the SSVC trees. `ssvc_v2.py` has two methods: `applier_tree()` and `developer_tree()` The two methods just loop through their respective lookup tables until they hit a match, then return the outcome. Maybe not the best implementation, but it worked well enough for what was needed at the time. + ## Local development Install prerequisites: @@ -70,19 +97,21 @@ Start a local server: mkdocs serve ``` -Navigate to http://localhost:8000/ to see the site. +Navigate to http://localhost:8001/ to see the site. -(Hint: You can use the `--dev-addr` argument with mkdocs to change the port, e.g. `mkdocs serve --dev-addr localhost:8001`) +(Hint: You can use the `--dev-addr` argument with mkdocs to change the port, e.g. `mkdocs serve --dev-addr localhost:8000`) ## Contributing -See [CONTRIBUTING.md](CONTRIBUTING.md) for high-level information, and the [SSVC Project Wiki](https://github.com/CERTCC/SSVC/wiki) -for more detail on how to contribute to the project. +- [SSVC Community Engagement](https://certcc.github.io/SSVC/about/contributing/) has more detail on how to contribute to the project. +- [SSVC Project Wiki](https://github.com/CERTCC/SSVC/wiki) for more detail how to contribute to the project (style guides, etc.) +- [CONTRIBUTING.md](CONTRIBUTING.md) for high-level information and legal details ## Citing SSVC To reference SSVC in an academic publication, please refer to the version presented at the 2020 Workshop on Economics of Information Security (WEIS): +``` @inproceedings{spring2020ssvc, title={Prioritizing vulnerability response: {A} stakeholder-specific vulnerability categorization}, author={Jonathan M Spring and Eric Hatleback and Allen D. Householder and Art Manion and Deana Shick}, @@ -91,6 +120,7 @@ To reference SSVC in an academic publication, please refer to the version presen month = dec, booktitle = {Workshop on the Economics of Information Security} } +``` ## References diff --git a/draft/ssvc.html b/draft/ssvc.html deleted file mode 100644 index a3305ddf..00000000 --- a/draft/ssvc.html +++ /dev/null @@ -1,5083 +0,0 @@ - - - - - - - - - - - - - SSVC – Prioritizing Vulnerability Response: A Stakeholder-Specific Vulnerability Categorization (SSVC) version 2.1.0-edb6c97 - - - - -
-

Prioritizing Vulnerability Response: A -Stakeholder-Specific Vulnerability Categorization (SSVC) version -2.1.0-edb6c97

-

Jonathan M. Spring

-

Eric Hatleback

-

Allen D. Householder

-

Vijay S. Sarvepalli

-

Laurie Tyzenhaus

-

Charles G. Yarbrough

-

2023-09-01T15:03:59-04:00

-
-

Introduction

-

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

-

We will improve vulnerability management by framing decisions better. -The modeling framework determines what output types are possible, -identifies the inputs, determines the aspects of vulnerability -management that are in scope, defines the aspects of context that are -incorporated, identifies how to handle changes over time, describes how -the model handles context and different roles, and determines what those -roles should be. As such, the modeling framework is important but -difficult to pin down. We approach this problem as a satisficing -process. We do not seek optimal formalisms, but an adequate -formalism.

-

Our decision-making process is based on decision trees. A decision -tree represents important elements of a decision, possible decision -values, and possible outcomes. We suggest decision trees as an adequate -formalism for practical, widespread advice about vulnerability -prioritization. We do not claim this approach is the only viable option. -We suggest that specific vulnerability management stakeholder -communities use decision trees. These suggestions are hypotheses for -viable replacements for CVSS in those communities, but the hypotheses -require empirical testing before they can be justifiably considered fit -for use. We propose a methodology for such testing.

-

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

-

The document is organized as follows.

- -

Current state of practice

-

Vulnerability management covers “the discovery, -analysis, and handling of new or reported security vulnerabilities in -information systems [and] the detection of and response to known -vulnerabilities in order to prevent them from being exploited” (Benetis et al. -2019). Prioritization of organizational and analyst resources is -an important precursor to vulnerability analysis, handling, and -response. The general problem is: given limited resources, which -vulnerabilities should be processed and which can be ignored for now. We -approach this problem from a pragmatic, practitioner-centered -perspective.

-

The de facto standard prioritization language is CVSS (“Review of Human -Decision-Making During Computer Security Incident Analysis” -2021). CVSS avoids discussing decisions and, instead, takes -technical severity as its fundamental operating -principle. However, the standard does not provide clear advice about how -CVSS scores might inform decisions (Wiles and Dugal 2019). SSVC instead -considers technical severity as one decision point in vulnerability -management. Severity should only be a part of vulnerability response -prioritization (See, e.g., Farris et al. 2018). -Vulnerability managers make decisions at a particular time in a specific -context. CVSS base scores are static; we will make SSVC from modular -parts that are easier to compose in each manager's temporal and -operational context.

-

Any re-adaptation of the basic CVSS mindset inherits its deeper -issues. For example, arguments for the CVSS scoring algorithm have not -been transparent and the standardization group has not justified the use -of the formula either formally or empirically (Jonathan M. Spring et al. 2018). One -complaint is that a high CVSS score does not predict which -vulnerabilities will be commonly exploited or have exploits publicly -released (Allodi and Massacci 2012). -Studies of consistency in CVSS scoring indicate that analysts do not -consistently interpret the elements of a CVSS version 3.0 score (Allodi et al. -2018). Because many adaptations of CVSS simply add additional -metrics, we expect they will inherit such inconsistency. Analyst -usability has so far been an afterthought, but we know from other areas -of information security that usability is not well-served as an -afterthought (Garfinkel and Lipford 2014). -SSVC aims to learn from and improve upon these issues.

-

Surveys of security metrics (Pendleton et al. 2016) and -information sharing in cybersecurity (Laube and Böhme 2017) 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 describes our design -goals for a pragmatic prioritization methodology that can improve and -build on the state of current practice.

-

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

-

Representing -Information for Decisions About Vulnerabilities

-

We propose that decisions about vulnerabilities—rather than their -severity—are a more useful approach. Our design goals for the -decision-making process are to

-
    -
  • clearly define whose decisions are involved
    • -
  • properly use evidentiary categories
    • -
  • be based on reliably available evidence
    • -
  • be transparent
    • -
  • be explainable
    • -
-

Our inspiration and justification for these design goals are that -they are the features of a satisfactory scientific enterprise (Jonathan M. Spring, Moore, -and Pym 2017) adapted to the vulnerability management -problem.

-

To consider decisions about managing the vulnerability rather than -just its technical severity, one must be clear about whose decisions are -involved. Organizations that produce patches and fix software clearly -have different decisions to make than those that deploy patches or other -security mitigations. For example, organizations in the aviation -industry have different priorities than organizations that make word -processors. These differences indicate a requirement: any formalism must -adequately capture the different decisions and priorities exhibited by -different groups of stakeholders. As a usability requirement, the number -of stakeholder groups needs to be small enough to be manageable, both by -those issuing scores and those seeking them.

-

The goal of adequacy is more appropriate than optimality. Our search -process need not be exhaustive; we are satisficing rather than -optimizing (Simon -1996). Finding any system that meets all of the desired criteria -is enough.

-

Decisions are not numbers. They are qualitative actions that an -organization can take. In many cases, numerical values can be directly -converted to qualitative decisions. For example, if your child’s -temperature is 105°F (40.5°C), you decide to go to the hospital -immediately. Conversion from numerical to qualitative values can be -complicated by measurement uncertainty and the design of the metrics. -For example, CVSS scores were designed to be accurate with +/- 0.5 -points of the given score (CVSS SIG 2019, sec. 7.5). Therefore, -under a Gaussian error distribution, 8.9 is really 60% high and 40% -critical since the recommended dividing line is 9.0. SSVC decisions -should be distinct and crisp, without such statistical overlaps.

-

We avoid numerical representations for either inputs or outputs of a -vulnerability management decision process. Quantified metrics are more -useful when (1) data for decision making is available, and (2) the -stakeholders agree on how to measure. Vulnerability management does not -yet meet either criterion. Furthermore, it is not clear to what extent -measurements about a vulnerability can be informative about other -vulnerabilities. Each vulnerability has a potentially unique -relationship to the socio-technical system in which it exists, including -the Internet.

-

Vulnerability management decisions are often contextual: given what -is known at the time, the decision is to do X. But what is known can -change over time, which can and should influence the decision. The -context of the vulnerability, and the systems it impacts, are -inextricably linked to managing it. 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.

-

We make the deliberation process as clear as is practical; therefore, -we risk belaboring some points to ensure our assumptions and reasoning -are explicit. Transparency should improve trust in the results.

-

Finally, any result of a decision-making process should be -explainable Explainable is defined and used with its -common meaning, not as it is used in the research area of explainable -artificial intelligence. An explanation should make the process -intelligible to an interested, competent, non-expert person. There are -at least two reasons common explainability is important: (1) for -troubleshooting and error correction and (2) for justifying proposed -decisions.

-

To summarize, the following are our design goals for a vulnerability -management process:

-
    -

  • Outputs are decisions.

    • -

  • Pluralistic recommendations are made among a manageable number of -stakeholder groups.

    • -

  • Inputs are qualitative.

    • -

  • Outputs are qualitative, and there are no (unjustified) shifts to -quantitative calculations.

    • -

  • Process justification is transparent.

    • -

  • Results are explainable.

    • -
-

Formalization Options

-

This section briefly surveys the available formalization options -against the six design goals described above. Table 1 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. -We focus on highlighting why some common options or suggestions do not -meet the above design goals. We argue that decision trees are a -satisfactory formalism.

-

We rule out many quantitative options, such as anything involving -statistical regression techniques or Bayesian belief propagation. Most -machine learning (ML) algorithms are also not suitable because they are -both unexplainable (in the common sense meaning) and quantitative. -Random forest algorithms may appear in scope since each individual -decision tree can be traced and the decisions explained (Russell and Norvig -2011). However, they are not transparent enough to simply know -how the available decision trees are created or mutated and why a -certain set of them works better. In any case, random forests are -necessary only when decision trees get too complicated for humans to -manage. We demonstrate below that in vulnerability management, useful -decision trees are small enough for humans to manage.

-

Logics are generally better suited for capturing qualitative -decisions. Boolean first-order logic is the “usual” logic—with material -implication (if/then), negation, existential quantification, and -predicates. For example, in program verification, satisfiability problem -(SAT) and satisfiability modulo theories (SMT) solvers are used to -automate decisions about when some condition holds or whether software -contains a certain kind of flaw. While the explanations provided by -logical tools are accessible to experts, non-experts may struggle. Under -special conditions, logical formulae representing decisions about -categorization based on exclusive-or conditions can be more compactly -and intelligibly represented as a decision tree.

-

Decision trees are used differently in operations research than in -ML. In ML, decision trees are used as a predictive model to classify a -target variable based on dependent variables. In operations research and -decision analysis, a decision tree is a tool that is used to document a -human process. In decision analysis, analysts “frequently use -specialized tools, such as decision tree techniques, to evaluate -uncertain situations” (Howard and Matheson 1983, viii). -We use decision trees in the tradition of decision analysis, not ML.

- - --------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
How Vulnerability -Prioritization Options Meet the Design Goals
Outputs are -DecisionsPluralisticQualitative InputsQualitative -OutputsTransparentExplainable
Parametric Regression❌❌✅❌❌✅
CVSS v3.0❌❌✅❌❌❌
Bayesian Belief Networks❌Maybe❌❌✅✅
Neural Networks❌❌❌❌❌❌
Random Forest✅✅✅Maybe❌Maybe
Other ML❌Maybe❌❌❌❌
Boolean First Order LogicsMaybeMaybe✅✅✅Maybe
Decision Trees✅✅✅✅✅✅
-

Decision Trees

-

A decision tree is an acyclic structure where nodes represent aspects -of the decision or relevant properties and branches represent possible -options for each aspect or property. Each decision point can have two or -more options.

-

Decision trees can be used to meet all of the design goals, even -plural recommendations and transparent tree-construction processes. -Decision trees support plural recommendations because a separate tree -can represent each stakeholder group. The opportunity for transparency -surfaces immediately: any deviation among the decision trees for -different stakeholder groups should have a documented reason—supported -by public evidence when possible—for the deviation. Transparency may be -difficult to achieve, since each node in the tree and each of the values -need to be explained and justified, but this cost is paid -infrequently.

-

There has been limited but positive use of decision trees in -vulnerability management. For example, Vulnerability Response Decision -Assistance (VRDA) studies how to make decisions about how to respond to -vulnerability reports (Manion et al. 2009). This paper -continues roughly in the vein of such work to construct multiple -decision trees for prioritization within the vulnerability management -process.

-

Representation choices

-

A decision tree can represent the same content in different ways. -Since a decision tree is a representation of logical relationships -between qualitative variables, the equivalent content can be represented -in other formats as well. The R package data.tree -has a variety of both internal representations and visualizations.

-

For data input, we elected to keep SSVC simpler than R, and just use -a CSV (or other fixed-delimiter separated file) as canonical data input. -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. 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). 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 through significant 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.

-

The tree visualization options are more diverse. We provide an -example format, and codified it in src/SSVC_csv-to-latex.py. -Why have we gone to this trouble when (for example) the R data.tree -package has a handy print-to-ASCII function? Because this function -produces output like the following:

-
1    start                                        
-2     ¦--AV:N                                     
-3     ¦   ¦--AC:L                                 
-4     ¦   ¦   ¦--PR:N
-...
-31    ¦   ¦   ¦   ¦   ¦   ¦       ¦--A:L    Medium
-32    ¦   ¦   ¦   ¦   ¦   ¦       °--A:N    Medium
-33    ¦   ¦   ¦   ¦   ¦   °--C:N                  
-34    ¦   ¦   ¦   ¦   ¦       ¦--I:H              
-35    ¦   ¦   ¦   ¦   ¦       ¦   ¦--A:H  Critical
-

This sample is a snippet of the CVSS version 3.0 base scoring -algorithm represented as a decision tree. The full tree can be found in -doc/graphics/cvss_tree_severity-score.txt. -This tree representation is functional, but not as flexible or aesthetic -as might be hoped. The visualizations provided by R are geared towards -analysis of decision trees in a random forest ML model, rather than -operations-research type trees.

-

Vulnerability Management -Decisions

-

This section will define our audience for decision advice and how we -are scoping our advice on vulnerability management decisions. Viable -decision guidance for vulnerability management should (at a minimum) -consider the stakeholder groups, their potential decision outcomes, and -the data needed for relevant decision points. This section covers the -first of these three parts, and the following sections address the other -parts in turn. The “who” is primarily about categories of -stakeholders—suppliers, deployers, and coordinators—as well as their -individual risk tolerances. The “what” is about the scope, both in how -the affected system is defined and how much of the world an analyst -should consider when estimating effects of a vulnerability.

-

While we strive to make our examples realistic, we invite the -community to engage and conduct empirical assessments to test them. The -following construction should be treated as an informed hypothesis -rather than a conclusion.

-

Enumerating Stakeholders

-

Stakeholders in vulnerability management can be identified within -multiple independent axes. For example, they can be identified by their -responsibility: whether the group supplies, deploys, -or coordinates remediation actions. Depending what task a team -is performing in a supply chain, the team may be considered a supplier, -deployer, or a coordinator. Therefore, one organization may have teams -that take on different roles. For example, an organization that develops -and uses its own software might delegate the supplier role to its -development team and the deployer role to its IT operations team. On the -other hand, organizations using a DevOps approach to providing services -might have a single group responsible for both the supplier and deployer -roles. Organizations may also be distinguished by the type of industry -sector. While it might be useful to enumerate all the sectors of the -economy, we propose to draft decision points that include those from -multiple important sectors. For example, we have safety-related -questions in the decision path for all suppliers and deployers. The -decision will be assessed whether or not the stakeholder is in a -safety-critical sector.

-

The choice not to segregate the decisions by sector is reinforced by -the fact that any given software system might be used by different -sectors. It is less likely that one organization has multiple -responsibilities within the vulnerability management process. Even if -there is overlap within an organization, the two responsibilities are -often located in distinct business units with distinct decision-making -processes. We can treat the responsibilities as non-overlapping, and, -therefore, we can build two decision trees—one for each of the “patch -supplier” and “patch deployer” responsibilities in the vulnerability -management process. We leave “coordinating patches” as future work. Each -of these trees will have different decision points that they take to -arrive at a decision about a given unit of work. -

-

The next two sections describe the decision space and the relevant -decision points that we propose for these two responsibilities within -the vulnerability management process.

-

The target audience for this paper is professional staff responsible -for making decisions about information systems. This audience -encompasses a broad class of professionals, including suppliers, system -maintainers, and administrators of many types. It also includes other -roles, such as risk managers, technical managers, and incident -responders. Although every layperson who owns a computing device makes -decisions about managing it, they are not the target audience. The -following decision system may help such laypeople, but we do not intend -it to be used by that audience.

-

While C-level executives and public policy professionals often make, -shape, or incentivize decisions about managing information systems, they -are not the target audience, either. To the extent that decision trees -for vulnerability management help higher level policy decisions, we -believe the best way to help policy makers is by making technical -decisions more transparent and explainable. Policy makers may see -indirect benefits, but they are not our primary audience and we are not -designing an approach for them directly.

-

Enumerating Decisions

-

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

-

Enumerating -Vulnerability Management Actions

-

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. 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.

-

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

-
    -
  • 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)
    • -
-

Without belaboring the point, the above methods are similar to how -CVE Numbering Authorities discern “independently fixable -vulnerabilities” (CVE -Board 2020). We also note that SBOM(Jump and Manion 2019) seems -well-placed to aid in that resolution process for the third-party -library scenarios.

-

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

-

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. The -relationship between SSVC and asset management is discussed further in -Relationship to 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 -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

-

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” (Office of the DoD Chief Information Officer -2020, sec. 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.

-

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.

- - ---- - - - - - - - - - - - - - - - - - - - - - - - - -
Proposed Meaning for -Supplier Priority Outcomes
Supplier PriorityDescription
DeferDo not work on the patch at present.
ScheduledDevelop a fix within regularly scheduled -maintenance using supplier resources as normal.
Out-of-CycleDevelop mitigation or remediation -out-of-cycle, taking resources away from other projects and releasing -the fix as a security patch when it is ready.
ImmediateDevelop 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. Table 3 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 from -open to controlled. Financial well-being, a Safety Impact category, might be -reduced with adequate fraud detection and insurance. Physical -well-being, also a Safety Impact -category, might be reduced by physical barriers that restrict a robot's -ability to interact with humans. 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 to reduce the complexity of the tree.

-

However, these mitigation techniques will not always work. For -example, the implementation of a firewall or IDS rule to mitigate System Exposure 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 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; Exposure; Utility; and Human Impact. In this order, an active state of Exploitation will never result in a -defer priority. A none -state of Exploitation (no evidence -of exploitation) will result in either defer or -scheduled priority—unless the state of Human Impact is very high, resulting in an -out-of-cycle priority.

-

As opposed to mitigation, applying a remediation finishes an SSVC -analysis of a deployed system. 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.

- - ---- - - - - - - - - - - - - - - - - - - - - - - - - -
Proposed Meaning for -Deployer Priority Outcomes
Deployer PriorityDescription
DeferDo not act at present.
ScheduledAct during regularly scheduled maintenance -time.
Out-of-cycleAct more quickly than usual to apply the -mitigation or remediation out-of-cycle, during the next available -opportunity, working overtime if necessary.
ImmediateAct 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 (Householder, Wassermann, et al. 2020, -sec. 6.10). The second decision is whether to publish information -about a vulnerability. We omit a table for this decision because the -options are do not publish or publish.

- - ---- - - - - - - - - - - - - - - - - - - - - -
Proposed Coordinator -Triage Priority Outcomes
Triage PriorityDescription
DeclineDo not act on the report.
TrackReceive information about the -vulnerability and monitor for status changes but do not take any overt -actions.
CoordinateTake action on the report. “Action” may -include any one or more of: technical analysis, reproduction, notifying -vendors, publication, and assist another party.
-

Items With the Same Priority

-

Within each setting, the decisions are a kind of equivalence class -for priority. That is, if an organization must deploy patches for three -vulnerabilities, and if these vulnerabilities are all assigned the -scheduled priority, then the organization can decide which to -deploy first. The priority is equivalent. This approach may feel -uncomfortable since CVSS gives the appearance of a finer grained -priority. CVSS appears to say, “Not just 4.0 to 6.9 is ‘medium’ -severity, but 4.6 is more severe than 4.5.” However, as discussed -previously (see page 4), CVSS is designed to be accurate only within +/- -0.5, and, in practice, is scored with errors of around +/- 1.5 to 2.5 -(Allodi et al. -2018, see Figure 1). An error of this magnitude is enough to make -all of the “normal” range from 4.0 to 6.9 equivalent, because 5.5 +/- -1.5 is the range 4.0 to 7.0. Our proposal is an improvement over this -approach. CVSS errors often cross decision boundaries; in other words, -the error range often includes the transition between “high” and -“critical” or “medium.” Since our approach keeps the decisions -qualitatively defined, this fuzziness does not affect the results.

-

Returning to the example of an organization with three -vulnerabilities to remediate that were assigned scheduled -priority, in SSVC, they can be patched in any order. This is an -improvement over CVSS, since based on the scoring errors, CVSS was -essentially just giving random fine-grained priorities within -qualitative categories anyway. With our system, organizations can be -more deliberate about conveniently organizing work that is of equivalent -priority.

-

Risk Tolerance and -Response Priority

-

SSVC enables stakeholders to balance and manage their risks -themselves. We follow the risk management vocabulary from (ISO 2009) and define risk as -“effect of uncertainty on objectives;” see (ISO 2009) for notes on the terms in the -definition. A successful vulnerability management practice must balance -at least two risks:

-
    -
  1. Change risk: the potential costs of deploying remediation, which -include testing and deployment in addition to any problems that could -arise from making changes to production systems.
    2. -
  2. Vulnerability risk: the potential costs of incidents resulting from -exploitation of vulnerable systems
    3. -
-

To place these risks in context, we follow the SEI's Taxonomy of -Operational Cyber Security Risks (Cebula and Young 2010). Change -risk can be characterized as a combination of Class 2 and/or Class 3 -risks. Class 2: Systems and Technology Failures includes hardware, -software, and systems risks. Class 3: Failed Internal Processes can -arise from process design, process execution, process controls, or -supporting processes. Meanwhile, vulnerability risk falls into Subclass -1.2: Actions of People: Deliberate.

-

In developing the decision trees in this document, we had in mind -stakeholders with a moderate tolerance for risk. The resulting trees -reflect that assumption. Organizations may of course be more or less -conservative in their own vulnerability management practices, and we -cannot presume to determine how an organization should balance their -risk.

-

We therefore remind our readers that the labels on the trees (defer, -immediate, etc.) can and should be customized to suit the needs of -individual stakeholders wherever necessary and appropriate. For example, -an organization with a high aversion to change risk might choose to -accept more vulnerability risk by lowering the overall response labels -for many branches in the trees, resulting in fewer vulnerabilities -attaining the most urgent response. On the other hand, an organization -with a high aversion to vulnerability risk could elevate the priority of -many branches to ensure fixes are deployed quickly.

-

Scope

-

Scope is an important variable in the answers of these decision -points. It has at least three aspects. The first is how the boundaries -of the affected system are set. The second is whose security policy is -relevant. The third is how far forward in time or causal steps one -reasons about effects and harms. We put forward recommendations for each -of these aspects of scope.

-

However, users of the decision process may want to define different -scopes. Users may define a different scope as long as the scope (1) is -consistent across decisions, and (2) is credible, explicit, and -accessible to all relevant decision makers.

-

For example, suppliers often decline to support products beyond a -declared end-of-life (EOL) date. In these cases, a supplier could -reasonably consider vulnerabilities in those products to be out of -scope. However, a deployer may still have active instances of EOL -products in their infrastructure. It remains appropriate for a deployer -to use SSVC to prioritize their response to such situations, since even -if there is no remediation forthcoming from the supplier it may be -possible for the deployer to mitigate or remediate the vulnerability in -other ways, up to and including decommissioning the affected -system(s).

-

Boundaries of the Affected -System

-

One distinction is whether the system of interest is software per se -or a cyber-physical system. A problem is that in every practical case, -both are involved. Software is what has vulnerabilities and is what -vulnerability management is focused on remediating. Multiple pieces of -software run on any given computer system. To consider software -vulnerabilities in a useful scope, we follow prior work and propose that -a vulnerability affects “the set of software instructions that executes -in an environment with a coherent function and set of permissions” (Jonathan M. Spring, -Kern, and Summers 2015). This definition is useful because it -lets us keep to common usage and intuition and call the Linux kernel—at -least a specific version of it—“one piece” of software.

-

But decision points about safety and mission impact are not about the -software in isolation; they are about the entire cyber-physical system, -of which the software is a part. The term “physical” in “cyber-physical -system” should be interpreted broadly; selling stocks or manipulating -press outlet content are both best understood as affecting human social -institutions. These social institutions do not have much of a corporeal -instantiation, but they are physical in the sense that they are not -merely software, and so are parts of cyber-physical systems.

-

The hard part of delineating the boundaries of the affected system is -specifying what it means for one system to be part of another system. -Just because a computer is bolted to a wall does not mean the computer -is part of the wall’s purpose, which is separating physical space. At -the same time, an off-premises DNS server may be part of the site -security assurance system if the on-premises security cameras rely on -the DNS server to connect to the displays at the guard’s desk. We define -computer software as part of a cyber-physical system if the two systems -are mutually manipulable; that is, changes in the part (the software) -will (at least, often) make detectable and relevant changes to the whole -(the cyber-physical system), and changes in the whole will (often) make -relevant and detectable changes in the part (Jonathan M. Spring and Illari -2018).

-

When reasoning about a vulnerability, we assign the vulnerability to -the nearest, relevant—yet more abstract—discrete component. This -assignment is particularly important when assessing technical impact on -a component. This description bears some clarification, via each of the -adjectives:

-
    -

  • Nearest is relative to the abstraction at which -the vulnerability exists.

    • -

  • Relevant implies that the impacted component -must be in the chain of abstraction moving upward from the location of -the flaw.

    • -

  • More abstract means that the impacted component -is at least one level of abstraction above the specific location of the -vulnerability. For example, if the vulnerability is localized to a -single line of code in a function, then the function, the module, the -library, the application, the product, and the system it belongs to are -all “more abstract.”

    • -

  • Discrete means there is an identifiable thing -that can be remediated (e.g., the unit of patching).

    • -
-

Products, libraries, and applications tend to be appropriate objects -of focus when seeking the right level to analyze the impact of a -vulnerability. For example, when reasoning about the technical impact of -a vulnerability that is localized to a function in a module in an open -source library, the nearest relevant discrete abstraction is the library -because the patches are made available at the library level. Similarly, -analysis of a vulnerability in closed source database software that -supports an enterprise resource management (ERM) system would consider -the technical impact to the database, not to the ERM system.

-

Relevant Security Policy

-

Our definition of a vulnerability includes a security policy -violation, but it does not clarify whose security policies are relevant -(Householder, -Wassermann, et al. 2020). For an organizational PSIRT or CSIRT, -the organization's security policy is most relevant. The answer is less -clear for coordinators or ISACs. An example scenario that brings the -question into focus is phone OS jailbreak methods. The owner of the -phone may elect to jailbreak it; there is at least an implicit security -policy from the owner that allows this method. However, from the -perspective of the explicit phone OS security policy embedded in the -access controls and separation of privileges, the jailbreak is -exploiting a vulnerability. If a security policy is embedded in -technical controls, such as OS access controls on a phone, then anything -that violates that security policy is a vulnerability.

-

Reasoning Steps Forward

-

This aspect of scope is about immediacy, prevalence, and causal -importance. Immediacy is about how soon after the -decision point adverse effects should occur to be considered relevant. -Prevalence is about how common adverse effects should -be to be considered relevant. Causal importance is -about how much an exploitation of the software in the cyber-physical -system contributes to adverse effects to be considered relevant. Our -recommendation is to walk a pragmatic middle path on all three aspects. -Effects are not relevant if they are merely possible, too infrequent, -far distant, or unchanged by the vulnerability. But effects are relevant -long before they are absolutely certain, ubiquitous, or occurring -presently. Overall, we summarize this aspect of scope as consider -credible effects based on known use cases of the software system as a -part of cyber-physical systems.

-

Likely Decision Points -and Relevant Data

-

We propose the following decision points and associated values should -be a factor when making decisions about vulnerability prioritization. -Each decision point is tagged with the stakeholder it is relevant to: -deployers, suppliers, or both. We emphasize that these descriptions are -hypotheses to be further tested and validated. We made every effort to -put forward informed and useful decision frameworks with wide -applicability, but the goal of this paper is more to solicit feedback -than make a declaration. We welcome questions, constructive criticism, -refuting evidence, or supporting evidence about any aspect of this -proposal.

-

One important omission from the values for each category is an -“unknown” option. Instead, we recommend explicitly identifying an option -that is a reasonable assumption based on prior events. Such an option -requires reliable historical evidence for what tends to be the case; of -course, future events may require changes to these assumptions over -time. Therefore, our assumptions require evidence and are open to debate -in light of new evidence. Different risk tolerance or risk discounting -postures are not addressed in the current work; accommodating such -tolerance or discounting explicitly is an area for future work. This -flexibility fits into our overall goal of supplying a decision-making -framework that is both transparent and fits the needs of different -communities. Resisting an “unknown” option discourages the modeler from -silently embedding these assumptions in their choices for how the -decision tree flows below the selection of any “unknown” option.

-

We propose satisfactory decision points for vulnerability management -in the next sections, in no particular order. Each section has a -subsection with advice on gathering information about the decision -point. SSVC using -Current Information Sources will provide some suggestions about how -existing sources of information about vulnerabilities can be used to -collate responses to these decision points.

-

Exploitation

-
-

Evidence of Active Exploitation of a Vulnerability

-
-

The intent of this measure is the present state of exploitation of -the vulnerability. The intent is not to predict future exploitation but -only to acknowledge the current state of affairs. Predictive systems, -such as EPSS, could be used to augment this decision or to notify -stakeholders of likely changes (Jacobs et al. 2021).

- - ---- - - - - - - - - - - - - - - - - - - - - -
Exploitation Decision Values
ValueDefinition
NoneThere is no evidence of active -exploitation and no public proof of concept (PoC) of how to exploit the -vulnerability.
PoC
(Proof of Concept)		One of the following cases is true: (1) -exploit code is sold or traded on underground or restricted fora; (2) a -typical public PoC in places such as Metasploit or ExploitDB; or (3) the -vulnerability has a well-known method of exploitation. Some examples of -condition (3) are open-source web proxies serve as the PoC code for how -to exploit any vulnerability in the vein of improper validation of TLS -certificates. As another example, Wireshark serves as a PoC for packet -replay attacks on ethernet or WiFi networks. A publicly-known hard-coded -or default password would also meet this criteria.
ActiveShared, observable, reliable evidence that -the exploit is being used in the wild by real attackers; there is -credible public reporting.
-

Gathering Information -About Exploitation

-

(Householder, Chrabaszcz, et al. -2020) presents a method for searching the GitHub repositories of -open-source exploit databases. 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), perhaps we could construct a mapping of CWE-IDs -which always represent vulnerabilities with well-known methods of -exploitation. For example, CWE-295, Improper -Certificate Validation, and its child CWEs, describe improper -validation of TLS certificates. These CWE-IDs could always be marked as -PoC since that meets condition (3) in the -definition. A comprehensive set of suggested CWE-IDs for this purpose is -future work.

-

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 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; however, one should not assume -it is complete.

-

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 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 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).

-

Technical Impact

-
-

Technical Impact of Exploiting the Vulnerability

-
-

When evaluating Technical -Impact, recall the scope definition in the Scope Section. 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, 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.

- - ---- - - - - - - - - - - - - - - - - -
Technical Impact Decision Values
ValueDefinition
PartialThe exploit gives the adversary -limited control over, or information exposure about, the -behavior of the software that contains the vulnerability. Or the exploit -gives the adversary an importantly low stochastic opportunity for total -control. In this context, “low” means that the attacker cannot -reasonably make enough attempts to overcome the low chance of each -attempt not working. Denial of service is a form of limited control over -the behavior of the vulnerable component.
TotalThe exploit gives the adversary -total control over the behavior of the software, or it gives -total disclosure of all information on the system that contains the -vulnerability
-

Gathering -Information About Technical Impact

-

Assessing Technical Impact -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. After exploiting the vulnerability,

-
    -
  • can the attacker install and run arbitrary software?
    • -
  • can the attacker trigger all the actions that the vulnerable -component can perform?
    • -
  • 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 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.

-

Automatable

-

Automatable captures the answer -to the question “Can an attacker reliably automate creating exploitation -events for this vulnerability?” This metric can take the values -no or yes:

-
    -
  • no: Attackers cannot reliably -automate steps 1-4 of the kill chain (Hutchins, Cloppert, and Amin -2011) for this vulnerability. These steps are (1) reconnaissance, -(2) weaponization, (3) delivery, and (4) exploitation. Reasons why a -step may not be reliably automatable could include the following: -
      -
    1. the vulnerable component is not searchable or enumerable on the -network,
      2. -
    2. weaponization may require human direction for each target,
      3. -
    3. delivery may require channels that widely deployed network security -configurations block, and
      4. -
    4. exploitation is not reliable, due to exploit-prevention techniques -enabled by default; ASLR is an example of an exploit-prevention -tool.
      5. -
    • -
  • yes: Attackers can reliably -automate steps 1-4 of the kill chain. If the vulnerability allows remote -code execution or command injection, the expected response should be -yes.
    • -
-

Due to vulnerability chaining, there is some nuance as to whether -reconnaissance can be automated. For example, consider a vulnerability -A. If the systems vulnerable to A are usually not openly connected to -incoming traffic (that is, Exposure is -small or controlled), -reconnaissance probably cannot be automated (scans would be blocked, -etc.). This would make Automatable equal to no 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.

-

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. 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 to Automatable.

-

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 (Bano et al. 2018). 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, 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.

-

Value Density

-

Value Density is described as -diffuse or concentrated based on the resources that -the adversary will gain control over with a single exploitation -event:

-
    -

  • diffuse: The system that -contains the vulnerable component has limited resources. That is, the -resources that the adversary will gain control over with a single -exploitation event are relatively small. Examples of systems with -diffuse value are email accounts, most consumer online banking accounts, -common cell phones, and most personal computing resources owned and -maintained by users. (A “user” is anyone whose professional task is -something other than the maintenance of the system or component. As with -Safety Impact, a “system operator” -is anyone who is professionally responsible for the proper operation or -maintenance of a system.)

    • -

  • concentrated: The system -that contains the vulnerable component is rich in resources. -Heuristically, such systems are often the direct responsibility of -“system operators” rather than users. Examples of concentrated value are -database systems, Kerberos servers, web servers hosting login pages, and -cloud service providers. However, usefulness and uniqueness of the -resources on the vulnerable system also inform value density. For -example, encrypted mobile messaging platforms may have concentrated -value, not because each phone’s messaging history has a particularly -large amount of data, but because it is uniquely valuable to law -enforcement.

    • -
-

Gathering Information -About Value Density

-

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.

-

An analyst might use market research reports or Internet telemetry -data to assess an unfamiliar product. Organizations such as Gartner -produce research on the market position and product comparisons for a -large variety of systems. These generally identify how a product is -deployed, used, and maintained. An organization's own marketing -materials are a less reliable indicator of how a product is used, or at -least how the organization expects it to be used.

-

Network telemetry can inform how many instances of a software system -are connected to a network. 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.

-

Utility

-
-

The Usefulness of the Exploit to the Adversary

-
-

Utility estimates an adversary's -benefit compared to their effort based on the assumption that they can -exploit the vulnerability. Utility is -independent from the state of Exploitation, which measures whether a -set of adversaries have ready access to exploit code or are in fact -exploiting the vulnerability. In economic terms, Exploitation measures whether the -capital cost of producing reliable exploit code has -been paid or not. Utility estimates the -marginal cost of each exploitation event. More plainly, -Utility is about how much an adversary -might benefit from a campaign using the vulnerability in question, -whereas Exploitation is about how -easy it would be to start such a campaign or if one is already -underway.

-

Heuristically, we base Utility on a combination of the value density -of vulnerable components and whether potential exploitation is -automatable. This framing makes it easier to analytically derive these -categories from a description of the vulnerability and the affected -component. Automatable as (no or yes) and Value Density as (diffuse or concentrated) 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 Utility -Decision Values. The next table is an -equivalent expression of Utility that -resembles a lookup table in a program.

- - ---- - - - - - - - - - - - - - - - - - - - - -
Utility Decision Values
ValueDefinition
LaboriousNo to automatable and diffuse -value
Efficient{Yes to automatable and diffuse -value} OR {No to automatable and concentrated value}
Super EffectiveYes to automatable and -concentrated value
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Utility to the Adversary, as a Combination of Automatable and -Value Density
AutomatableValue DensityUtility
nodiffuselaborious
noconcentratedefficient
yesdiffuseefficient
yesconcentratedsuper effective
-

Alternative Utility Outputs

-

Alternative heuristics can plausibly be used as proxies for adversary -utility. One example is the value of the vulnerability if it were sold -on the open market. Some firms, such as Zerodium, make such pricing -structures public. The valuable exploits track the Automatable and Value Density heuristics for the most -part. Within a single system—whether it is Apache, Windows, iOS or -WhatsApp—more successfully automated steps in the kill lead to higher -exploit value. Remote code execution with sandbox escape and without -user interaction are the most valuable exploits, and these features -describe automation of the relevant kill chain steps.

-

How equivalently Automatable -exploits for different systems are priced relative to each other is more -idiosyncratic. Price does not only track the Value Density of the system, but -presumably also the existing supply of exploits and the installation -distribution among the targets of Zerodium’s customers. Currently, we -simplify the analysis and ignore these factors. However, future work -should look for and prevent large mismatches between the outputs of the -Utility decision point and the exploit -markets.

-

Safety Impact

-
-

Safety Impacts of Affected System Compromise

-
-

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) 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. -

-

The stakeholder should consider the safety impact on the system -operators (by “system operator,” we mean those who are professionally -responsible for the proper operation of the cyber-physical system, as -the term is used in the safety analysis literature) and users of the -software they provide. If software is repackaged and resold by a -stakeholder to further downstream entities who will then sell a product, -the initial stakeholder can only reasonably consider so many links in -that supply chain. However, a stakeholder should know its immediate -consumers who are one step away in the supply chain. Those consumers may -repackage or build on the software and then provide that product further -on.

-

We expect that a stakeholder should be aware of common usage of their -software about one step away in the supply chain. This expectation holds -in both open source and proprietary contexts. Further steps along the -supply chain are probably not reasonable for the stakeholder to consider -consistently; however, this is not a license to willfully ignore common -downstream uses of the stakeholder’s software. If the stakeholder is -contractually or legally responsible for safe operation of the software -or cyber-physical system of which it is part, that also supersedes our -rough supply-chain depth considerations.

-

For software used in a wide variety of sectors and deployments, the -stakeholder may need to estimate an aggregate safety impact. Aggregation -suggests that the stakeholder’s response to this decision point cannot -be less than the most severe credible safety impact, but we leave the -specific aggregation method or function as a domain-specific extension -for future work.

-

Gathering Information -About Safety Impact

-

The factors that influence the safety impact level are diverse. This -paper does not exhaustively discuss how a stakeholder should answer a -question; that is a topic for future work. At a minimum, understanding -safety impact should include gathering information about survivability -of the vulnerable component, determining available operator actions to -compensate for the vulnerable component, understanding relevant -insurance, and determining the viability of existing backup measures. -Because each of these information items depends heavily on -domain-specific knowledge, it is out of the scope of this paper to give -a general-purpose strategy for how they should be included. For example, -viable manual backup mechanisms are likely to be important in assessing -the safety impact of an industrial control system in a sewage plant, but -in banking the insurance structures that prevent bankruptcies are more -important.

-

The decision values for safety impact are based on the hazard -categories for aircraft software (RTCA, Inc. 2012; FAA 2000, sec. -3.3.2). To assign a value to Safety -Impact, at least one type of harm must reach that value. For -example, for a Safety Impact of major, at least one type of harm must -reach major level. All types of -harm do not need to rise to the level of major, just one type of harm -does.

- - ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Safety Impact Decision Values
ValueType of HarmDefinition
NoneAllDoes not mean no impact -literally; the effect is below the threshold for all aspects -described in Minor
MinorPhysical HarmPhysical discomfort for users of the -system OR a minor occupational safety hazard OR reduction in physical -system safety margins
MinorEnvironmentMinor externalities (property damage, -environmental damage, etc.) imposed on other parties
MinorFinancialFinancial losses, which are not readily -absorbable, to multiple persons
MinorPsychologicalEmotional or psychological harm, -sufficient to be cause for counseling or therapy, to multiple -persons
MajorPhysical HarmPhysical distress and injuries for users -of the system OR a significant occupational safety hazard OR failure of -physical system functional capabilities that support safe operation
MajorEnvironmentMajor externalities (property damage, -environmental damage, etc.) imposed on other parties
MajorFinancialFinancial losses that likely lead to -bankruptcy of multiple persons
MajorPsychologicalWidespread emotional or psychological -harm, sufficient to be cause for counseling or therapy, to populations -of people
HazardousPhysical HarmSerious or fatal injuries, where -fatalities are plausibly preventable via emergency services or other -measures OR parts of the cyber-physical system that support safe -operation break
HazardousEnvironmentSerious externalities (threat to life as -well as property, widespread environmental damage, measurable public -health risks, etc.) imposed on other parties
HazardousFinancialSocio-technical system (elections, -financial grid, etc.) of which the affected component is a part is -actively destabilized and enters unsafe state
HazardousPsychologicalN/A
CatastrophicPhysical HarmMultiple immediate fatalities (emergency -response probably cannot save the victims.)
CatastrophicEnvironmentExtreme externalities (immediate public -health threat, environmental damage leading to small ecosystem collapse, -etc.) imposed on other parties
CatastrophicFinancialSocial systems (elections, financial grid, -etc.) supported by the software collapse
CatastrophicPsychologicalN/A
- - -

Public Safety Impact

-

Suppliers necessarily have a rather coarse-grained perspective on the -broadly defined safety impacts described above. Therefore we simplify -the above into a binary categorization: Significant is when any -impact meets the criteria for an impact of Major, Hazardous, or -Catastrophic in the above table. Minimal is when none do.

- - - - - - - - - - - - - - - - - - -
Public Safety Impact Decision Values
ValueDefinition
MinimalSafety Impact of None or Minor
SignificantSafety Impact of Major, Hazardous, or -Catastrophic
-

Situated Safety Impact

-

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 to simplify implementation for deployers.

-

Mission Impact

-
-

Impact on Mission Essential Functions of the Organization

-
-

A mission essential function (MEF) is a function -“directly related to accomplishing the organization’s mission as set -forth in its statutory or executive charter” (Fenton 2017, A–1). Identification and -prioritization of mission essential functions enables effective -continuity planning or crisis planning. Mission Essential Functions are -in effect critical activities within an organization that are used to -identify key assets, supporting tasks, and resources that an -organization requires to remain operational in a crises situation, and -so must be included in its planning process. During an event, key -resources may be limited and personnel may be unavailable, so -organizations must consider these factors and validate assumptions when -identifying, validating, and prioritizing MEFs.

-

When reviewing the list of organizational functions, an organization -must first identify whether a function is essential or non-essential. -The distinction between these two categories is whether or not an -organization must perform a function during a disruption to normal -operations and must continue performance during emergencies (Fenton 2017, B–2). -Essential functions are both important and urgent. Functions that can be -deferred until after an emergency are identified as non-essential. For -example, DoD defines MEFs in DoD -Directive 3020.26 DoD Continuity Policy using similar terminology to -FCD-2 -(“DoD -Directive 3020.26 DoD Continuity Policy” 2018).

-

As mission essential functions are most clearly defined for -government agencies, stakeholders in other sectors may be familiar with -different terms of art from continuity planning. For example, -infrastructure providers in the US may better align with National -Critical Functions. Private sector businesses may better align with -operational -and financial impacts in a business -continuity plan.

-

While the processes, terminology, and audience for these different -frameworks differ, they all can provide a sense of the criticality of an -asset or assets within the scope of the stakeholder conducting the cyber -vulnerability prioritization with SSVC. In that sense they all function -quite similarly within SSVC. Organizations should use whatever is most -appropriate for their stakeholder context, with Mission Essential -Function analysis serving as a fully worked example in the SSVC -documents.

- - ---- - - - - - - - - - - - - - - - - - - - - - - - - -
Mission Impact Decision Values
ValueDefinition
DegradedLittle to no impact up to degradation of -non-essential functions; chronic degradation would eventually harm -essential functions
MEF Support CrippledActivities that directly support essential -functions are crippled; essential functions continue for a time
MEF FailureAny one mission essential function fails -for period of time longer than acceptable; overall mission of the -organization degraded but can still be accomplished for a time
Mission FailureMultiple or all mission essential -functions fail; ability to recover those functions degraded; -organization’s ability to deliver its overall mission fails
-

Gathering -Information About Mission Impact

-

The factors that influence the mission impact level are diverse. This -paper does not exhaustively discuss how a stakeholder should answer a -question; that is a topic for future work. At a minimum, understanding -mission impact should include gathering information about the critical -paths that involve vulnerable components, viability of contingency -measures, and resiliency of the systems that support the mission. There -are various sources of guidance on how to gather this information; see -for example the FEMA guidance in Continuity Directive 2 (Fenton 2017) or OCTAVE -FORTE (Tucker -2018). 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 might -constrain Mission Impact if both -are not used in the same decision tree. For example, if the Utility is super -effective, then Mission -Impact is at least MEF support -crippled.

-

Human Impact

-
-

Combined Situated Safety and Mission Impact

-
-

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 Situated Safety and Mission Impact 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. -Therefore we combine the two lesser mission impacts of degraded and MEF -support crippled into a single category, while retaining the distinction -between MEF Failure and Mission Failure at the extreme. This gives us -three levels of mission impact to work with.

-

On the other hand, most organizations tend to have lower tolerance -for variance in safety. Even small deviations in safety are unlikely to -go unnoticed or unaddressed. We suspect that the presence of regulatory -oversight for safety issues and its absence at the lower end of the -mission impact scale influences this behavior. Because of this higher -sensitivity to safety concerns, we chose to retain a four-level -resolution for the safety dimension. We then combine Mission Impact with -Situated Safety impact and map them onto a 4-tiered scale (Low, Medium, -High, Very High). The mapping is shown in the following table.

- - ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Combining Mission and Situated Safety Impact into Human -Impact
Situated Safety ImpactMission ImpactCombined Value (Human Impact)
None/MinorDegraded/CrippledLow
None/MinorMEF FailureMedium
None/MinorMission FailureVery High
MajorDegraded/CrippledMedium
MajorMEF FailureHigh
MajorMission FailureVery High
HazardousDegraded/CrippledHigh
HazardousMEF FailureHigh
HazardousMission FailureVery High
CatastrophicDegraded/CrippledVery High
CatastrophicMEF FailureVery High
CatastrophicMission FailureVery High
- - -

Safety -and Mission Impact Decision Points for Industry Sectors

-

We expect to encounter diversity in both safety and mission impacts -across different organizations. However, we also anticipate a degree of -commonality of impacts to arise across organizations within a given -industry sector. For example, different industry sectors may have -different use cases for the same software. Therefore, vulnerability -information providers—that is, vulnerability databases, 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.

-

System Exposure

-
-

The Accessible Attack Surface of the Affected System or Service

-
-

Measuring the attack surface precisely is difficult, and we do not -propose to perfectly delineate between small and controlled access. -Exposure should be judged against the system in its deployed context, -which may differ from how it is commonly expected to be deployed. For -example, the exposure of a device on a vehicle's CAN bus will vary -depending on the presence of a cellular telemetry device on the same -bus.

-

If a vulnerability cannot be remediated, other mitigations may be -used. Usually, the effect of these mitigations is to reduce exposure of -the vulnerable component. Therefore, a deployer’s response to Exposure -may change if such mitigations are put in place. If a mitigation changes -exposure and thereby reduces the priority of a vulnerability, that -mitigation can be considered a success. Whether that mitigation allows -the deployer to defer further action varies according to each case.

- - ---- - - - - - - - - - - - - - - - - - - - - -
System Exposure Decision Values
ValueDefinition
SmallLocal service or program; highly -controlled network
ControlledNetworked service with some access -restrictions or mitigations already in place (whether locally or on the -network). A successful mitigation must reliably interrupt the -adversary’s attack, which requires the attack is detectable both -reliably and quickly enough to respond. Controlled covers the -situation in which a vulnerability can be exploited through chaining it -with other vulnerabilities. The assumption is that the number of steps -in the attack path is relatively low; if the path is long enough that it -is implausible for an adversary to reliably execute it, then -exposure should be small.
OpenInternet or another widely accessible -network where access cannot plausibly be restricted or controlled (e.g., -DNS servers, web servers, VOIP servers, email servers)
-

Gathering -Information About 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. 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 can be -readily informed by network scanning techniques. For example, if the -vulnerable component is visible on Shodan 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 -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 -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.
    • -
  • If Automatable is yes, 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 vs scheduled, 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.

-

Decisions During -Vulnerability Coordination

-

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. 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 (Householder, Wassermann, et al. -2020).

-

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.

-

Different coordinators have different scopes and constituencies. See -(Householder, -Wassermann, et al. 2020, 3.5) 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.

-

Coordination Triage -Decisions

-

We take three priority levels in our decision about whether and how -to coordinate a vulnerability (Householder, Wassermann, et al. 2020, -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 (Benetis et al. 2019) 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; coordination makes use of Utility and -Public Safety Impact 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

-

Is a viable report of the details of the vulnerability already -publicly available?

-
    -
  • Yes
    • -
  • No
    • -
-

Supplier Contacted

-

Has the reporter made a good-faith effort to contact the supplier of -the vulnerable component using a quality contact method?

-
    -
  • Yes
    • -
  • No
    • -
-

A quality contact method is a publicly posted known good email -address, public portal on vendor website, etc.

-

Supplier Cardinality

-

How many suppliers are responsible for the vulnerable component and -its remediation or mitigation plan?

-
    -
  • One
    • -
  • Multiple
    • -
-

Supplier Engagement

-

Is the supplier responding to the reporter's contact effort and -actively participating in the coordination effort?

-
    -
  • Active
    • -
  • Unresponsive
    • -
-

Report Credibility

-

Assessing the credibility of a report is complex, but the assessment -must reach a conclusion of either:

-
    -
  • Credible
    • -
  • Not credible
    • -
-

An analyst should start with a presumption of credibility and proceed -toward disqualification. The reason for this is that, as a coordinator, -occasionally doing a bit of extra work on a bad report is preferable to -rejecting legitimate reports. This is essentially stating a preference -for false positives over false negatives with respect to credibility -determination.

-

The following subsections provide suggestive guidance on assessing -credibility. There are no ironclad rules for this assessment, and other -coordinators may find other guidance works for them. Credibility -assessment topics include indicators for and against credibility, -perspective, topic, and relationship to report scope.

-

Credibility Indicators

-

The credibility of a report is assessed by a balancing -test. The indicators for or against are not commensurate, and so -they cannot be put on a scoring scale, summed, and weighed.

-

A report may be treated as credible when either (1) the vendor -confirms the existence of the vulnerability or (2) independent -confirmation of the vulnerability by an analyst who is neither the -reporter nor the vendor. If neither of these confirmations are -available, then the value of the Report Credibility decision -point depends on a balancing test among the following indicators.

-

Indicators for Credibility include:

-
    -
  • The report is specific about what is affected
    • -
  • The report provides sufficient detail to reproduce the -vulnerability.
    • -
  • The report describes an attack scenario.
    • -
  • The report suggests mitigations.
    • -
  • The report includes proof-of-concept exploit code or steps to -reproduce.
    • -
  • Screenshots and videos, if provided, support the written text of the -report and do not replace it.
    • -
  • The report neither exaggerates nor understates the impact.
    • -
-

Indicators against Credibility include:

-
    -
  • The report is “spammy” or exploitative (for example, the report is -an attempt to upsell the receiver on some product or service).
    • -
  • The report is vague or ambiguous about which vendors, products, or -versions are affected (for example, the report claims that all “cell -phones” or “wifi” or “routers” are affected).
    • -
  • The report is vague or ambiguous about the preconditions necessary -to exploit the vulnerability.
    • -
  • The report is vague or ambiguous about the impact if exploited.
    • -
  • The report exaggerates the impact if exploited.
    • -
  • The report makes extraordinary claims without correspondingly -extraordinary evidence (for example, the report claims that exploitation -could result in catastrophic damage to some critical system without a -clear causal connection between the facts presented and the impacts -claimed).
    • -
  • The report is unclear about what the attacker gains by exploiting -the vulnerability. What do they get that they didn't already have? For -example, an attacker with system privileges can already do lots of bad -things, so a report that assumes system privileges as a precondition to -exploitation needs to explain what else this gives the attacker.
    • -
  • The report depends on preconditions that are extremely rare in -practice, and lacks adequate evidence for why those preconditions might -be expected to occur (for example, the vulnerability is only exposed in -certain non-default configurations—unless there is evidence that a -community of practice has established a norm of such a non-default -setup).
    • -
  • The report claims dire impact for a trivially found vulnerability. -It is not impossible for this to occur, but most products and services -that have been around for a while have already had their low-hanging -fruit major vulnerabilities picked. One notable exception would be if -the reporter applied a completely new method for finding vulnerabilities -to discover the subject of the report.
    • -
  • The report is rambling and is more about a narrative than describing -the vulnerability. One description is that the report reads like a food -recipe with the obligatory search engine optimization preamble.
    • -
  • The reporter is known to have submitted low-quality reports in the -past.
    • -
  • The report conspicuously misuses technical terminology. This is -evidence that the reporter may not understand what they are talking -about.
    • -
  • The analyst's professional colleagues consider the report to be not -credible.
    • -
  • The report consists of mostly raw tool output. Fuzz testing outputs -are not vulnerability reports.
    • -
  • The report lacks sufficient detail for someone to reproduce the -vulnerability.
    • -
  • The report is just a link to a video or set of images, or lacks -written detail while claiming “it's all in the video”. Imagery should -support a written description, not replace it.
    • -
  • The report describes a bug with no discernible security impact.
    • -
  • The report fails to describe an attack scenario, and none is -obvious.
    • -
-

We considered adding poor grammar or spelling as an indicator of -non-credibility. On further reflection, we do not recommend that poor -grammar or spelling be used as an indicator of low report quality, as -many reporters may not be native to the coordinator's language. Poor -grammar alone is not sufficient to dismiss a report as not credible. -Even when poor grammar is accompanied by other indicators of -non-credibility, those other indicators are sufficient to make the -determination.

-

Credibility of what to whom

-

SSVC is interested in the coordinating analyst's assessment of the -credibility of a report. This is separate from the fact that a reporter -probably reports something because they believe the report is -credible.

-

The analyst should assess the credibility of the report of the -vulnerability, not the claims of the impact of the vulnerability. A -report may be credible in terms of the fact of the vulnerability's -existence even if the stated impacts are inaccurate. However, the more -extreme the stated impacts are, the more skepticism is necessary. For -this reason, “exaggerating the impact if exploited” is an indicator -against credibility. Furthermore, a report may be factual but -not identify any security implications; such reports are bug reports, -not vulnerability reports, and are considered out of scope.

-

A coordinator also has a scope defined by their specific constituency -and mission. A report can be entirely credible yet remain out of scope -for your coordination practice. Decide what to do about out of scope -reports separately, before the vulnerability coordination triage -decision begins. If a report arrives and would be out of scope even if -true, there will be no need to proceed with judging its credibility.

-

Coordination Triage -Decision Process

-

The decision tree for reaching a Decision involves seven -decision points. The first two function as gating questions:

- -

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 -or PDF

-

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.

-

The publication decision is always a decision at a point in time. As -discussed in Guidance on -Communicating Results, 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. 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.
    • -
  • 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 -and the status of the vulnerability. CERT/CC only expects to publish -about vulnerabilities with a coordinate status. -While an issue that is tracked or declined may be reevaluated at a later -date and status changed to coordinate, unless -that happens we would not publish about the vulnerability. Other -organizations, such as NVD, would -have different publication criteria and may want to include decision -points or the decision itself from the Coordination Triage Decisions -in their publication decision.
    • -
-

In addition to the two decision points defined in this section, the -publication decision uses the Exploitation decision point.

-

Public Value Added

-

This decision point asks how much value a publication from the -coordinator would benefit the broader community. The value is based on -the state of existing public information about the vulnerablity.

-
    -
  • 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.
    • -
-

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.

-

Supplier Involvement

-

This decision point accounts for the state of the supplier's work on -addressing the vulnerability.

-
    -

  • Fix Ready—the supplier has provided a patch or -fix.

    • -

  • Cooperative—the supplier is actively generating a patch -or fix; they may or may not have provided a mitigation or work-around in -the mean time.

    • -

  • Uncooperative/Unresponsive—the supplier has not -responded, declined to generate a remediation, or no longer exists.

    -

    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:

- -

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 and gather evidence to make -decisions. How this decision information might be stored or communicated -is the topic of subsections on Asset Management and Communication.

-

Supplier Tree

-

The example supplier tree 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:

-
    -
  • Defer = gray with green outline
    • -
  • Scheduled = yellow
    • -
  • Out-of-Cycle = orange
    • -
  • Immediate = red with black outline
    • -
-
- - -
- -

Deployer Tree

-

The example deployer tree PDF is depicted -below.

-
- - -
- -

Coordinator Trees

-

As described in Decisions During -Vulnerability Coordination, a coordination stakeholder usually makes -separate triage and publication decisions. Each have trees presented -below.

-

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.

-

Publication Decision Tree

-

Suggested decision values for this decision are available in CSV and PDF formats.

-
- - -
- -

Tree Construction -and Customization Guidance

-

Stakeholders are encouraged to customize the SSVC decision process to -their needs. Indeed, the first part of SSVC stands for -“stakeholder-specific." However, certain parts of SSVC are more amenable -to customization than others. In this section, we'll cover what a -stakeholder should leave static, what we imagine customization looks -like, and some advice on building a usable and manageable decision tree -based on our experience so far.

-

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 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.

-

Which decision points are involved in a vulnerability management -team's decision and the priority label for each resulting situation are, -for all intents and purposes, totally at the discretion of the team. We -have provided some examples for different stakeholder communities here. -What decision points a team considers reflects what it cares about and -the risks prioritizes. Different teams may legitimately prioritize -different objectives. It should be easier for teams to discuss and -communicate such differences if the definitions of the decision points -remain static. The other aspect of risk management that SSVC allows a -team to customize is its risk appetite or risk tolerance.

-

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, total Technical Impact, and efficient Utility -might be handled with scheduled priority by one team -and out-of-cycle 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.

-

When doing the detailed risk management work of creating or modifying -a tree, we recommend working from text files with one line or row for -each unique combination of decision values. For examples, see SSVC/data. -An important benefit, in our experience, is that it is easier to -identify a question by saying “I'm unsure about row 16” than anything -else we have thought of so far. Once the humans agree on the decision -tree, it can be converted to a JSON schema for easier machine-readable -communication, following the provided SSVC -provision JSON schema.

-

Once the decision points are selected and the prioritization labels -agreed upon, it is convenient to be able to visually compress the text -file by displaying it as a decision tree. Making the decision process -accessible has a lot of benefits. Unfortunately, it also makes it a bit -too easy to overcomplicate the decision.

-

The academic literature surrounding the measurement of decision tree -quality is primarily concerned with measuring classification errors -given a particular tree and a labeled data set. In our case, we are not -attempting to fit a tree to data. Rather, we are interested in producing -usable trees that minimize extraneous effort. To that end, we briefly -examine the qualities for which decision tree measurement is -suitable.

-

Decision Tree Construction -Concerns

-

Decision tree construction methods must address five significant -concerns:

-
    -
  • feature selection
    • -
  • feature type
    • -
  • overfitting
    • -
  • parsimony
    • -
  • versioning
    • -
-

Feature selection

-

Feature selection is perhaps the most important consideration for -SSVC, because it directly affects the information gathering requirements -placed on the analyst attempting to use the tree. Each decision point in -SSVC is a feature.

-

The SSVC version 1 ~applier~ deployer tree had 225 rows when we wrote -it out in long text form. It only has four outcomes to differentiate -between. Thus, on average that decision process treats one situation -(combination of decision values) as equivalent to 65 other situations. -If nothing else, this means analysts are spending time gathering -evidence to make fine distinctions that are not used in the final -decision. The added details also make it harder for the decision process -to accurately manage the risks in question. This difficulty arises -because more variance and complexity there is in the decision increases -the possibility of errors in the decision process itself.

-

Feature types

-

Regarding feature types, all of the features included in SSVC version -2 can be considered ordinal data. That is, while they can be ordered -(e.g., for Exploitation, active is greater than poc is greater than -none), they can not be compared via subtraction or division (active - -poc = nonsense). The use of ordinal features is a key assumption behind -our use of the parsimony analysis that follows.

-

Overfitting

-

When decision trees are used in a machine learning context, -overfitting increases tree complexity by incorporating the noise in the -training data set into the decision points in a tree. In our case, our -“data” is just the set of outcomes as decided by humans, so overfitting -is less of a concern, assuming the feature selection has been done with -care.

-

Parsimony

-

Parsimony is, in essence, Occam's Razor applied to tree selection. -Given the choice between two trees that have identical outputs, one -should choose the tree with fewer decisions. One way to evaluate the -parsimony of a tree is by applying the concept of feature importance to -ensure that each feature is contributing adequately to the result. While -there are a few ways to compute feature importance, the one we found -most useful is permutation importance. Permutation importance can be -calculated on a candidate tree to highlight potential issues. It works -by randomly shuffling the values for each feature individually and -comparing a fitness metric on the shuffled tree to the original. The -change in fitness is taken to be the importance of the feature that was -shuffled. Permutation importance is usually given as a number in the -interval [0,1]. Python's scikit-learn (Pedregosa et al. 2011) -provides a permutation importance method, which we used to evaluate our -trees.

-

Interpreting the results of a permutation importance computation on a -tree involves nuance, but one rule we can state is this: any feature -with a computed permutation importance of zero can be eliminated from -the tree without losing any relevant information. When all of the -permutation importance scores for all features are relatively equal, -that is an indication that each feature is approximately equally -relevant to the decision.

-

More likely, however, is that some subset of features will be of -relatively equal importance, and one might be of considerably lower -importance (yet not zero). In this case, the lowest importance feature -should be considered for refinement or elimination. It is possible that -adjusting the definition of a feature or its available values (whether -redefining, adding, or removing options) could increase its importance. -Reasons to retain a low-importance feature include:

-
    -
  • the feature is relevant to a small set of important circumstances -that a tree without the feature would otherwise be unable to -discriminate
    • -
  • the effort required to determine the correct value for the feature -is relatively small, for example information that might be collected -automatically
    • -
  • the feature enables other features to be defined more clearly -Features that meet none of the above criteria may be good candidates for -elimination.
    • -
-

Customizing a tree by changing the outcome priority labels can also -affect the importance of a feature. This sort of customization is often -the simplest way to adjust the importance of a feature.

-

While there is no hard and fast rule for when a tree is too big, we -suggest that if all of your outcomes are associated with more than 15 -situations (unique combinations of decision values), you would benefit -from asking whether your analysts actually use all the information they -would be gathering. Thus, 60 unique combinations of decision values is -the point at which a decision tree with four distinct outcomes is, on -average, potentially too big.

-

Tree Versioning

-

SSVC trees should be identifiable by name and version. A tree name is -simply a short descriptive label for the tree derived from the -stakeholder and/or function the tree is intended for. Tree versions are -expected to share the major and minor version numbers with the SSVC -version in which their decision points are defined. Revisions should -increment the patch number. For example: “Applier Tree v1.1.0” would be -the identity of the version of the Applier Tree as published in version -1.1 of SSVC. “Coordinator Publish Tree v2.0.3” would be the identity of -a future revision of the Coordinator Publish Tree as described in this -document. The terms “major”, “minor”, and “patch” with respect to -version numbering are intended to be consistent with Semantic Versioning -2.0.0.

-

Sharing Trees With Others

-

Communities of shared interest may desire to share information about -decision points or even create custom trees to share within their -community. Examples include:

-
    -
  • an Information Sharing and Analysis Organization (ISAO) within a -critical infrastructure sector might want to define a custom decision -point relevant to their constituents' regulatory compliance.
    • -
  • a corporate Computer Security Incident Response Team (CSIRT) might -choose to adjust decision priorities for an existing tree for use by its -subsidiaries.
    • -
  • a government department might define a separate tree using existing -decision points to address a particular governance process within their -constituent agencies.
    • -
  • a regional coordinator might want to produce decision point -information as a product of its threat analysis work and provide this -information to its constituency in an advisory.
    • -
-

In these and other scenarios, there are two scopes to consider:

-
    -
  1. Decision Point Scope
    2. -
  2. Decision Tree Scope
    3. -
-

Decision Point Scope

-

Each decision point defined in this document has a characteristic -scope, either stakeholder-agnostic or -stakeholder-specific.

-
    -
  • Stakeholder-agnostic decision points describe the -state of the world outside the stakeholder's environment. One might -think of them as global facts that form the background context in which -the stakeholder is making a prioritization decision. 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 value might be consistent across all subsidiaries for -a centrally managed service.
    • -
-

We generally consider the following decision points to be -stakeholder-agnostic:

- -

On the contrary, we consider the following decision points to be -stakeholder-specific:

- -

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

-
    -
  • A decision point indicating whether a system or mission context is -affected by regulatory oversight that might alter the decision priority. -E.g., a healthcare-focused ISAO might define a decision point about -whether a vulnerability affects patient data privacy protection.
    • -
  • A decision point that incorporates the concept of change risk to a -deployer. E.g., a financial institution might have a very low tolerance -for changes to a transaction clearing system.
    • -
  • A decision point that indicates whether the affected software -belongs to a list of critical software for a specific constituency. -E.g., an open-source consortium might want to prioritize fix development -for a set of key projects.
    • -
-

Decision Tree Scope

-

Two kinds of modifications are possible at the decision tree -level.

-
    -
  • A Risk Appetite Shift retains the structure of an existing -tree and all its decision points, and simply adjusts the decision -outputs according to the stakeholder's risk appetite. For example, an -organization with sufficient resources to efficiently deploy fixes might -choose to defer fewer cases than the default tree would recommend.
    • -
  • Tree Customization can be done in one of three ways: -
      -
    1. incorporating an already-defined decision point into an existing -tree that does not already contain it.
      2. -
    2. defining a new decision point and adding it to an existing tree. -Note that adding or removing an option from an existing decision point -should be treated as creating a new decision point. The new decision -point should be given a distinct name as well.
      3. -
    3. defining a new tree entirely from existing or new decision -points.
      4. -
    • -
-

Because tree customization changes the tree structure and implies the -addition or removal of leaf nodes, it will be necessary for the -organization to review the decision outputs in light of its risk -appetite as well.

-

Risk-shifted or customized trees can be shared among a community of -interest, of course. Further customization within each stakeholder -remains an option as well, although there is likely a diminishing return -on more than a few layers of customization for the same basic decision. -Of course, SSVC users might choose to construct other trees to inform -other decisions.

-

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.

-

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 to take the value of PoC 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. 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. 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.

-

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. 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 is open. If -the decision maker knows nothing about the environment in which the -device is used, we suggest assuming a major 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. Similarly, with 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 as a default. Exploitation needs no special default; -if adequate searches are made for exploit code and none is found, the -answer is none. If nothing is known -about Automatable, the safer answer -to assume is yes. Value Density should always be -answerable; if the product is uncommon, it is probably diffuse. The resulting decision set -{none, open, yes, medium} results in -a scheduled patch application in our recommended deployer tree.

-

Relationship to asset -management

-

Vulnerability management is a part of asset management. SSVC can -benefit from asset management practices and systems, particularly in -regard to automating data collection and answers for some decision -points. SSVC depends on asset management to some extent, particularly -for context on the cost and risk associated with changing or updating -the asset.

-

Asset management can help automate the collection of the Mission Impact, Situated Safety Impact, and -System Exposure 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.

-

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. There are at -least three aspects of asset management that may be important but are -out of scope for SSVC. First and most obvious is the transaction cost of -conducting the mitigation or remediation. System administrators are paid -to develop or apply any remediations or mitigations, and there may be -other transactional costs such as downtime for updates. Second is the -risk of the remediation or mitigation introducing a new error or -vulnerability. Regression testing is part of managing this type of risk. -Finally, there may be an operational cost of applying a remediation or -mitigation, representing an ongoing change of functionality or increased -overhead. A decision maker could order work within one SSVC priority -class (scheduled, out-of-cycle, etc.) based on these asset management -considerations, for example. Once the organization remediates or -mitigates all the high-priority vulnerabilities, they can then focus on -the medium-level vulnerabilities with the same effort spent on the -high-priority ones.

-

Asset management and risk management also drive some of the up-front -work an organization would need to do to gather some of the necessary -information. 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 2019). Emerging -standards like the Software Bill of Materials (SBOM) (Jump and Manion -2019) 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) 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.

-

Development Methodology

-

For this tabletop refinement, we could not select a mathematically -representative set of CVEs. The goal was to select a handful of CVEs -that would cover diverse types of vulnerabilities. The CVEs that we used -for our tabletop exercises are CVE-2017-8083, CVE-2019-2712, -CVE-2014-5570, and CVE-2017-5753. We discussed each one from the -perspective of supplier and deployer. We evaluated CVE-2017-8083 twice -because our understanding and descriptions had changed materially after -the first three CVEs (six evaluation exercises). After we were satisfied -that the decision trees were clearly defined and captured our -intentions, we began the formal evaluation of the draft trees, which we -describe in the next section.

-

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 and 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. -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.
    • -
  • 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 becomes T and Public Safety Impact 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 becomes Ms -and efficient 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. 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 -Public Safety Impact, total Technical Impact, and efficient Utility, -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 is equivalent to a decision tree and documents the full set -of logical statements that a stakeholder uses to make decisions. The computed -schema 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.
    • -
  • Remove any text in parentheses (and the parentheses -themselves).
    • -
  • Remove colon characters, if any (:).
    • -
  • Convert the string to lower 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.

-

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 may be laborious, efficient, or super effective. 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 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 is diffuse but does not know the value for Automatability. Then the analyst can -usefully restrict Utility to one of laborious or efficient. 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, are mostly static. For Utility to change, the market penetration -or deployment norms of a vulnerable component would have to meaningfully -change. Some, such as 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, 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, 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.

- -

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.

- -

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 (Cichonski et al. 2012), such practices -make the process less error-prone and facilitate after-action -reviews.

-

Changelog

-

Version 2.1 Changelog

-

This section summarizes the changes between SSVC 2.1 and SSVC -version 2.0. The details of what changes were made can be viewed on -the SSVC Github under the SSVC v2.1 -milestone.

-
    -
  • Introduced a demo SSVC Calc App which -became the basis for CISA's SSVC Calculator
    • -
  • Updated Deployer tree to use Automatable instead of Utility, which reduced the size from 108 -leaf nodes to 72.
    • -
  • Adjusted Deployer tree decisions based on stakeholder feedback
    • -
  • Adjusted Supplier tree decisions based on stakeholder feedback
    • -
  • Added section on Sharing Trees -With Others including a discussion of decision point scope and -decision tree scope.
    • -
  • Improved clarity of time-sensitivity of some decision points in Representing -Information for Decisions About Vulnerabilities
    • -
  • Improved description of Mission -Impact
    • -
  • Improved consistency of Public -Safety Impact usage throughout the document and tooling
    • -
  • Improved consistency of Human -Impact usage throughout the document
    • -
  • Clarified that known default passwords are an example of Exploitation:PoC
    • -
  • Clarified that unreachable code (as in unused library features) are -System Exposure:small
    • -
  • Mention DoD MEF definition in Mission -Impact
    • -
  • Updated references to EPSS -to reflect recent publications
    • -
  • Refactored markdown files to better track chapter and section -numbering, improving findability when editing
    • -
  • Automated HTML and PDF generation into a Github -Workflow
    • -
  • Updated python tools to maintain sync with current SSVC decision -models
    • -
  • Consolidated the SSVC document style guide into a single file in the -repository
    • -
  • Miscellaneous typo fixes and readability improvements (e.g., -headings, bulleted lists)
    • -
-

Version 2 Changelog

-

This section summarizes the changes between SSVC version 2 and SSVC -version 1.1 as published at the Workshop on the Ecnomics of -Information Security (WEIS 2020). The details of what changes were made -can be viewed on the SSVC GitHub issues -closed under the SSVC v2 Development project. We addressed -about 60 issues. About 10 issues identified “bugs” or errors in version -1.1. About 20 issues improved documentation of tools or improved the -clarity of document text. The remaining 30 issues were focused on -enhancing SSVC based on feedback received on version 1, though several -of the bug fixes and documentation improvements also provided -improvements. This section focuses on changes that provided -enhancements.

-

Coordinator stakeholder

-

Version 1 only considered two stakeholders: those who make software, -and those who use information systems. Version 2 introduces a -coordinator stakeholder and two distinct decisions for that stakeholder -group: vulnerability intake triage and publication about a -vulnerability. These decisions use some existing decision points, but -also introduce six new decision points to support coordinators in making -these decisions. The coordinator stakeholder is based on CERT/CC's -experience coordinating vulnerabilities.

-

Terminology changes

-

Some terms have been adjusted to better align with other usage in the -field or based on feedback. Therefore, “patch developer” became -supplier and “patch applier” became -deployer. These terms in version 2 better reflect the -stakeholder's relationship to the vulnerable component and also help -keep clear that SSVC is about prioritization of work items in -vulnerability management, not just patches. We have also generally -removed the word patch and instead use the more general “remediation” -for a complete fix and “mitigation” for actions that reduce risk but do -not remove a vulnerability from a system. “Virulence” was renamed Automatable in a effort to be more -direct and clear, rather than relying on an epidemiology metaphor. We -changed “out-of-band” to out-of-cycle.

-

Some concepts needed to be clarified or added. These changes are a -bit more substantive than the above terminology changes, but are -similar. For example, we clarified how end-of-life products are -prioritized with SSVC. We also clarified in Scope -concepts around vulnerability identificatin and disambiguation. Version -2 adopts an explicit definition of risk (from ISO Guide -73). We also differentiated between vulnerability risk, or that risk -arising from an unmanaged vulnerability in an information system, and -change risk, or that risk from modifying or updating an information -system to mitigate or remediate a vulnerability. SSVC version 2 focuses -on assessing and managing vulnerability risk, not change risk. This -stance was not explicit in SSVC version 1.

-

Improvements to decision -points

-

Version 1 had a decision point for well-being impact that was shared -between supplier and deployer -stakeholders. Since these types of stakeholder have access to different -information about safety and well-being, Version 2 splits this concept -into Public Safety Impact -and Situated Safety -Impact. The underlying definition remains largely the same. -However, Public Safety -Impact has fewer output options (it is less granular) in -recognition that a supplier or coordinator has less information about -the context of deployment than a deployer does.

-

In addition, based on feedback from SSVC users, the SSVC version 2 -recommended applier tree makes use of a combined value for Mission Impact and Situated Safety Impact. The -intuition behind this change is that if a person is going to die OR the -organization is going to fail (for example, go bankrupt), then the -organization will likely want to act with highest priority. Either -situation is sufficient to increase the priority, and there do not -appear to be situations where a low Mission Impact would mitigate a high -Situated Safety Impact or -vice versa. On the other hand, a low Utility or System Exposure may mitigate a high -mission or well-being impact. So the Version 2 recommended tree is more -usable than the Version 1 tree, thanks to these changes.

-

Tree management and -communication tools

-

The section Tree Construction -and Customization Guidance is largely new or revised. We produced -new software -tools for interacting with SSVC, which are documented in that -section. Version 2 adds reasoning behind why a stakeholder might -customize a decision tree, what aspects of the tree are best to -customize, tools for encoding custom trees in JSON, and scripts for -visualizing custom trees.

-

Similarly, the section on Guidance on Communicating -Results is largely new. The section presents both an abbreviated and -unabridged format for communicating SSVC information about a -vulnerability. This communication may be connected to the formats for -communicating a whole decision tree. Version 2 also addresses several -other questions about SSVC information management, such as handling -information changes over time, partial information, sourcing information -for each decision point, and how collection and analysis of SSVC -decision points can be automated.

-

Evaluation of the Draft -Trees

-

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. The study resulted in -several changes to the hypothesized trees; we capture those changes and -the reason for each of them in Pilot -Results. The version 1 supplier and deployer trees included the -improvements reported in Improvement Instigated by -the Pilot.

-

Pilot Methodology

-

The pilot study tested inter-rater agreement of decisions reached. -Each author played the role of an analyst in both stakeholder groups -(supplying and deploying) for nine vulnerabilities. We selected these -nine vulnerabilities based on expert analysis, with the goal that the -nine cases cover a useful series of vulnerabilities of interest. -Specifically, we selected three vulnerabilities to represent -safety-critical cases, three to represent regulated-systems cases, and -three to represent general computing cases.

-

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, for example, should take -the value of none, PoC, or active. 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.

-

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.

-

The structure of the pilot test is as follows. Table 11 provides an -example of the information provided to each analyst. The supplier -portfolio details use strikeout font because this decision -item was removed after the pilot. The decision procedure for each case -is as follows: for each analyst, for each vulnerability, for each -stakeholder group, do the following.

-
    -

  1. Start at the root node of the relevant decision tree (deployer or -supplier).

    2. -

  2. Document the decision branch that matches the vulnerability for -this stakeholder context.

    3. -

  3. Document the evidence that supports that decision.

    4. -

  4. Repeat this decision-and-evidence process until the analyst -reaches a leaf node in the tree.

    5. -
- - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Example of Scenario Information Provided to Analysts (Using -CVE-2019-9042 as the Example)
Information ItemDescription Provided to Analysts
Use of Cyber-Physical SystemSitemagic’s content management system -(CMS) seems to be fairly popular among smaller businesses because it -starts out with a free plan to use it. Then it gradually has small -increments in payment for additional features. Its ease-of-use, good -designs, and one-stop-shopping for businesses attracts a fair number of -clients. Like any CMS, it “manages the creation and modification of -digital content. These systems typically support multiple users in a -collaborative environment, allowing document management with different -styles of governance and workflows. Usually the content is a website” -(Wikipedia, -2019)
State of ExploitationAppears to be active exploitation of this -vulnerability according to NVD. They have linked to the exploit: http://www.iwantacve.cn/index.php/archives/116/.
Developer Portfolio -DetailsSitemagic is an open-source project. -The only thing the brand name applies to is the CMS, and it does not -appear to be part of another open-source umbrella. The project is under -active maintenance (i.e., it is not a dead project).
Technical Impact of ExploitAn authenticated user can upload a .php -file to execute arbitrary code with system privileges.
Scenario BlurbWe are a small business that uses -Sitemagic to help run our business. Sitemagic handles everything from -digital marketing and site design to facilitating the e-commerce -transactions of the website. We rely on this website heavily, even -though we do have a brick-and-mortar store. Many times, products are not -available in-store, but are available online, so we point many customers -to our online store.
Deployer MissionWe are a private company that must turn a -profit to remain competitive. We want to provide customers with a -valuable product at a reasonable price, while still turning a profit to -run the business. As we are privately held (and not public), we are free -to choose the best growth strategy (that is, we are not legally bound to -demonstrate quarterly earnings for shareholders and can take a -longer-term view if it makes us competitive).
Deployment of Affected SystemWe have deployed this system such that -only the web designer Cheryl and the IT admin Sally are allowed to -access the CMS as users. They login through a password-protected portal -that can be accessed anywhere in the world for remote administration. -The CMS publishes content to the web, and that web server and site are -publicly available.
-

This test structure produced a series of lists similar in form to the -contents of Table 12. Analysts also noted how much time they spent on -each vulnerability in each stakeholder group.

- - ----- - - - - - - - - - - - - - - -
Example Documentation of a Single Decision Point
Decision PointBranch SelectedSupporting Evidence
Exploitation=activeControlledThe CMS has a limited number of authorized -users, and the vulnerability is exploitable only by an authenticated -user
-

We evaluated inter-rater agreement in two stages. In the first stage, -each analyst independently documented their decisions. This stage -produced 18 sets of decisions (nine vulnerabilities across each of two -stakeholder groups) per analyst. In the second stage, we met to discuss -decision points where at least one analyst differed from the others. If -any analyst changed their decision, they appended the information and -evidence they gained during this meeting in the “supporting evidence” -value in their documentation. No changes to decisions were forced, and -prior decisions were not erased, just amended. After the second stage, -we calculated some statistical measures of inter-rater agreement to help -guide the analysis of problem areas.

-

To assess agreement, we calculate Fleiss’ kappa, both for the value -in the leaf node reached for each case and every decision in a case -(Fleiss and -Cohen 1973). Evaluating individual decisions is complicated -slightly because the different paths through the tree mean that a -different number of analysts may have evaluated certain items, and -Fleiss’ kappa requires a static number of raters. “Leaf node reached” is -described to pick out the specific path through the tree the analyst -selected and to treat that as a label holistically. Measuring agreement -based on the path has the drawback that ostensibly similar paths (for -example, paths that agree on 3 of 4 decisions) are treated as no more -similar than paths that agree on 0 of 4 decisions. The two measures of -agreement (per decision and per path) are complementary, so we report -both.

-

Pilot participant details

-

The pilot participants are the five authors plus one analyst who had -not seen the draft system before participating. Five of the six -participants had spent at least one year as professional vulnerability -analysts prior to the pilot (Spring was the exception). Three of the -participants had at least ten years of experience each. The participants -experience is primarily as coordinators at the CERT® Coordination -Center. On the one hand, this is a different perspective than either -suppliers or deployers; on the other, the coordinator role is an -information broker that often interacts with these perspectives (Householder, -Wassermann, et al. 2020, sec. 3).

-

These participant demographics limit the generalizability of the -results of the pilot. Even though the results cannot be systematically -generalized to other analysts, there are at least three benefits to -conducting the pilot among this limited demographic. First, it should -surface any material tacit disagreements about term usage among the -authors. Tacit agreements that are not explained in the text likely -survive the pilot study without being acknowledged, but places where the -authors tacitly disagreed should be surfaced. We found this to be the -case; Improvement -Instigated by the Pilot documents these results. Second, the pilot -provides a case study that demonstrate SSVC is at least possible for -some small group of analysts to use. This achievement is not large, but -it is a first step. Third, the pilot provides a proof of concept method -and metric that any vulnerability prioritization method could use to -examine usability for analysts more generally. While the effect of -education on vulnerability assessment with CVSS has been tested (Allodi et al. -2018), we are not aware of any current vulnerability -prioritization method that tests usability or agreement among analysts -as part of the development process. Future work on SSVC as well as -further development of other prioritization methods can benefit from -using the method described in the pilot. Future instances should use -more representative participant demographics.

-

Vulnerabilities used as -examples

-

The vulnerabilities used as case studies are as follows. All quotes -are from the National Vulnerability -Database (NVD) and are illustrative of the vulnerability; however, -during the study each vulnerability was evaluated according to -information analogous to that in Table 11.

-

Safety-Critical Cases

-
    -

  • CVE-2015-5374: “Vulnerability … in [Siemens] Firmware variant -PROFINET IO for EN100 Ethernet module… Specially crafted packets sent to -port 50000/UDP could cause a denial-of-service of the affected -device…”

    • -

  • CVE-2014-0751: “Directory traversal vulnerability in … GE -Intelligent Platforms Proficy HMI/SCADA - CIMPLICITY before 8.2 SIM 24, -and Proficy Process Systems with CIMPLICITY, allows remote attackers to -execute arbitrary code via a crafted message to TCP port 10212, aka -ZDI-CAN-1623.”

    • -

  • CVE-2015-1014: “A successful exploit of these vulnerabilities -requires the local user to load a crafted DLL file in the system -directory on servers running Schneider Electric OFS v3.5 with version -v7.40 of SCADA Expert Vijeo Citect/CitectSCADA, OFS v3.5 with version -v7.30 of Vijeo Citect/CitectSCADA, and OFS v3.5 with version v7.20 of -Vijeo Citect/CitectSCADA. If the application attempts to open that file, -the application could crash or allow the attacker to execute arbitrary -code.”

    • -
-

Regulated Systems Cases

-
    -

  • CVE-2018-14781: “Medtronic insulin pump [specific versions] when -paired with a remote controller and having the “easy bolus” and “remote -bolus” options enabled (non-default), are vulnerable to a capture-replay -attack. An attacker can … cause an insulin (bolus) delivery.”

    • -

  • CVE-2017-9590: “The State Bank of Waterloo Mobile … app 3.0.2 … -for iOS does not verify X.509 certificates from SSL servers, which -allows man-in-the-middle attackers to spoof servers and obtain sensitive -information via a crafted certificate.”

    • -

  • CVE-2017-3183: “Sage XRT Treasury, version 3, fails to properly -restrict database access to authorized users, which may enable any -authenticated user to gain full access to privileged database functions. -Sage XRT Treasury is a business finance management application. -…”

    • -
-

General Computing Cases

-
    -

  • CVE-2019-2691: “Vulnerability in the MySQL Server component of -Oracle MySQL (subcomponent: Server: Security: Roles). Supported versions -that are affected are 8.0.15 and prior. Easily exploitable vulnerability -allows high privileged attacker with network access via multiple -protocols to … complete DoS of MySQL Server.”

    • -

  • CVE-2019-9042: “[I]n Sitemagic CMS v4.4… the user can upload a -.php file to execute arbitrary code, as demonstrated by 404.php. This -can only occur if the administrator neglects to set FileExtensionFilter -and there are untrusted user accounts. …”

    • -

  • CVE-2017-5638: “The Jakarta Multipart parser in Apache Struts 2 -2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception -handling and error-message generation during file-upload attempts, which -allows remote attackers to execute arbitrary commands via crafted -[specific headers], as exploited in the wild in March 2017…”

    • -
-

Pilot Results

-

For each of the nine CVEs, six analysts rated the priority of the -vulnerability as both a supplier and deployer. Table 13 summarizes the -results by reporting the inter-rater agreement for each decision point. -For all measures, agreement (k) is above zero, which is -generally interpreted as some agreement among analysts. Below zero is -interpreted as noise or discord. Closer to 1 indicates more or stronger -agreement.

-

How close k should be to 1 before agreement can be -considered strong enough or reliable enough is a matter of some debate. -The value certainly depends on the number of options among which -analysts select. For those decision points with five options (mission -and safety impact), agreement is lowest. Although portfolio value has a -higher k than mission or safety impact, it may not actually -have higher agreement because portfolio value only has two options. The -results for portfolio value are nearly indistinguishable as far as level -of statistical agreement from mission impact and safety impact. The -statistical community does not have hard and fast rules for cut lines on -adequate agreement. We treat k as a descriptive statistic -rather than a test statistic.

-

Table 13 is encouraging, though not conclusive. k<0 is a -strong sign of discordance. Although it is unclear how close to 1 is -success, k<0 would be clear sign of failure. In some ways, -these results may be undercounting the agreement for SSVC as presented. -These results are for SSVC prior to the improvements documented in Improvement Instigated by -the Pilot, which are implemented in SSVC version 1. On the other -hand, the participant demographics may inflate the inter-rater agreement -based on shared tacit understanding through the process of authorship. -The one participant who was not an author surfaced two places where this -was the case, but we expect the organizational homogeneity of the -participants has inflated the agreement somewhat. The anecdotal feedback -from vulnerability managers at several organizations (including VMware -(Akbar 2020) -and McAfee) is about refinement and tweaks, not gross disagreement. -Therefore, while further refinement is necessary, this evidence suggests -the results have some transferability to other organizations and are not -a total artifact of the participant organization demographics.

- - ----------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Inter-Rater Agreement for Decision Points
Safety ImpactExploitationTechnical ImpactPortfolio ValueMission ImpactExposureDev ResultDeployer Result
Fleiss’ k0.1220.8070.6790.2570.1460.4800.2260.295
Disagreement range2,41,21,11,12,41,21,32,3
-

For all decision points, the presumed goal is for k to be -close or equal to 1. The statistics literature has identified some -limited cases in which Fleiss’ k behaves strangely—for example it is -lower than expected when raters are split between 2 of q ratings when -q>2 (Falotico -and Quatto 2015). This paradox may apply to the safety and -mission impact values, in particular. The paradox would bite hardest if -the rating for each vulnerability was clustered on the same two values, -for example, minor and major. Falotico and Quatto’s proposed solution is -to permute the columns, which is safe with unordered categorical data. -Since the nine vulnerabilities do not have the same answers as each -other (that is, the answers are not clustered on the same two values), -we happen to avoid the worst of this paradox, but the results for safety -impact and mission impact should be interpreted with some care.

-

This solution identifies another difficulty of Fleiss’ kappa, namely -that it does not preserve any order; none and catastrophic are -considered the same level of disagreement as none and minor. Table 13 -displays a sense of the range of disagreement to complement this -weakness. This value is the largest distance between rater selections on -a single vulnerability out of the maximum possible distance. So, for -safety impact, the most two raters disagreed was by two steps (none to -major, minor to hazardous, or major to catastrophic) out of the four -possible steps (none to catastrophic). The only values of k -that are reliably comparable are those with the same number of options -(that is, the same maximum distance). In other cases, closer to 1 is -better, but how close is close enough to be considered “good” changes. -In all but one case, if raters differed by two steps then there were -raters who selected the central option between them. The exception was -mission impact for CVE-201814781; it is unclear whether this discrepancy -should be localized to a poor test scenario description, or to SSVC’s -mission impact definition. Given it is an isolated occurrence, we expect -the scenario description at least partly.

-

Nonetheless, k provides some way to measure improvement on -this a conceptual engineering task. The pilot evaluation can be -repeated, with more diverse groups of stakeholders after the -descriptions have been refined by stakeholder input, to measure fit to -this goal. For a standard to be reliably applied across different -analyst backgrounds, skill sets, and cultures, a set of decision point -descriptions should ideally achieve k of 1 for each item in -multiple studies with diverse participants. Such a high level of -agreement would be difficult to achieve, but it would ensure that when -two analysts assign a priority with the system that they get the same -answer. Such agreement is not the norm with CVSS currently (Allodi et al. -2018).

- - ------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SSVC pilot scores compared with the CVSS base scores for the -vulnerabilities provided by NVD.
CVE-IDRepresentative SSVC decision valuesSSVC recommendation (supplier, -deployer)NVD’s CVSS base score
CVE-2014-0751E:N/T:T/U:L/S:H/X:C/M:C(Sched, OOC)7.5 (High) (v2)
CVE-2015-1014E:N/T:T/U:L/S:J/X:S/M:F(Sched, Sched)7.3 (High) (v3.0)
CVE-2015-5374E:A/T:P/U:L/S:H/X:C/M:F(Immed, Immed)7.8 (High) (v2)
CVE-2017-3183E:N/T:T/U:E/S:M/X:C/M:C(Sched, Sched)8.8 (High) (v3.0)
CVE-2017-5638E:A/T:T/U:S/S:M/X:U/M:C(Immed, OOC)10.0 (Critical) (v3.0)
CVE-2017-9590E:P/T:T/U:E/S:M/X:U/M:D(OOC, Sched)5.9 (Medium) (v3.0)
CVE-2018-14781E:P/T:P/U:L/S:H/X:C/M:F(OOC, OOC)5.3 (Medium) (v3.0)
CVE-2019-2691E:N/T:P/U:E/S:M/X:C/M:C(Sched, Sched)4.9 (Medium) (v3.0)
CVE-2019-9042E:A/T:T/U:L/S:N/X:C/M:C(OOC, Sched)7.2 (High) (v3.0)
-

Table 14 presents the mode decision point value for each -vulnerability tested, as well as the recommendation that would result -from that set based on the recommended decision trees in SSVC version 1. -The comparison with the NVD’s CVSS base scores mostly confirms that SSVC -is prioritizing based on different criteria, as designed. In particular, -differences in the state of exploitation and safety impact are -suggestive.

-

Based on these results, we made about ten changes, some bigger than -others. We did not execute a new rater agreement experiment with the -updated descriptions. The pilot results are encouraging, and we believe -it is time to open up a wider community discussion.

-

Improvements Instigated by -the Pilot

-

The following changes were reflected in the version 1 Section -"Decision Trees for Vulnerability Management."

-
    -

  • Technical impact: We clarified that partial/total is decided -regarding the system scope definition, which considers a database or a -web server program as the “whole” system. Furthermore, “total” also -includes any technical impact that exposes authentication credentials to -the adversary, if those credentials are to the whole system.

    • -

  • We added advice for information gathering to answer safety impact -and mission impact questions. This change is needed because of the -particularly wide variety of background assumptions analysts made that -influenced results and agreement.

    • -

  • We clarified that “MEF failure” refers to any -one essential function failing, not failure of all of -them. We changed most severe mission impact to “mission failure” to -better reflect the relationship between MEFs and the organization’s -mission.

    • -

  • We removed the “supplier portfolio value” question since it had -poor agreement, and there is no clear way to correct it. We replaced -this question with Utility, which better captures the relevant -kinds of value (namely, to the adversary) of the affected component -while remaining amenable to pragmatic analysis.

    • -

  • We clarified that “proof of concept” (see Exploitation) -includes cases in which existing tooling counts as a PoC. The examples -listed are suggestive, not exhaustive.

    • -

  • We reorganized the decision trees based on which items are easier -to gather information for or which ones have a widely verifiable state. -This change moved exploitation to the first question.

    • -

  • We changed the decision tree results such that if exposure is -“small,” then the resulting priority is lower than before the pilot -study. That is, “small” exposure has a stronger effect on reducing -urgency.

    • -
-

Questions Removed as -Ineffective

-

In this section, we present ideas we tried but rejected for various -reasons. We are not presenting this section as the final word on -excluding these ideas, but we hope the reasons for excluding them are -instructive, will help prevent others from re-inventing the proverbial -wheel, and can guide thinking on future work.

-

Initially, we brainstormed approximately 12 potential decision -points, most of which we removed early in our development process -through informal testing. These decision points included adversary’s -strategic benefit of exploiting the vulnerability, state of legal or -regulatory obligations, cost of developing remediation, patch -distribution readiness, financial losses to customers due to potential -exploitation, and business losses to the deployer.

-

Some of these points left marks on other decision points. The -decision point “financial losses of customers” led to an amendment of -the definition of Safety to include “well-being,” such that, -for example, bankruptcies of third parties are now a major safety -impact. The “business losses to the deployer” decision point is covered -as a mission impact insofar as profit is a mission of publicly traded -corporations.

-

Three of the above decision points left no trace on the current -system. “State of legal or regulatory obligations,” “cost of developing -remediation,” and “patch distribution readiness” were dropped as either -being too vaguely defined, too high level, or otherwise not within the -scope of decisions by the defined stakeholders. The remaining decision -point, “adversary’s strategic benefit of exploiting the vulnerability,” -transmuted to a different sense of system value. In an attempt to be -more concrete and not speculate about adversary motives, we considered a -different sense of value: supplier portfolio value.

-

The only decision point that we have removed following the pilot is -developer portfolio value. This notion of value was essentially an -over-correction to the flaws identified in the “adversary’s strategic -benefit of exploiting the vulnerability” decision point. “Supplier -portfolio value” was defined as “the value of the affected component as -a part of the developer’s product portfolio. Value is some combination -of importance of a given piece of software, number of deployed instances -of the software, and how many people rely on each. The developer may -also include lifecycle stage (early development, stable release, -decommissioning, etc.) as an aspect of value.” It had two possible -values: low and high. As Table 13 demonstrates, there was relatively -little agreement among the six analysts about how to evaluate this -decision point. We replaced this sense of portfolio value with -Utility, which combines Value Density and -Automatability.

-

Worked Example

-

As an example, we will evaluate CVE-2018-14781 step by step from the -deployer point of view. The scenario here is that used for the pilot -study. This example uses the SSVC version 1 deployer decision tree.

-

The analyst’s first question is related to exploitation. Technically, -one could answer the questions in any order; however, exploitation is a -good starting point because given an adequately defined search -procedure, one can always answer whether it finds an available exploit -or proof of concept. The scenario description for the pilot study reads -as follows:

-
    -
  • State of exploitation: Metasploit and ExploitDB do -not return results for this vulnerability. The NVD does not report any -active exploitation of this vulnerability.
    • -
-

This information rules out “active” given the (perhaps limited) -search procedure. While the search did not produce a precise PoC, based -on the description of the vulnerability, it is a fairly standard traffic -capture and replay attack that, given access to the transmission medium, -should be straightforward to conduct with Wireshark. Therefore, we -select the “PoC” branch and then ask about exposure. This considers the -(fictional) deployer scenario blurb and the notional deployment of the -affected system, as follows.

-
    -

  • Scenario blurb: We are a hospital that uses -Medtronic devices frequently because of their quality and popularity in -the market. We give these devices out to clients who need to monitor and -track their insulin intake. If clients need to access data on their -device, they can physically connect it to their computer or connect via -Bluetooth to an app on their phone for monitoring capabilities. -Occasionally, clients who use this device will have a doctor’s -appointment in which the doctors have machines that can access the -device as well to monitor or change settings. It is unknown how secure -the doctor’s computer that interfaces directly with this insulin pump -is. If the doctor’s computer is compromised, it potentially means that -every device that connects to it is compromised as well. If an update to -the insulin pump is required, a client can do this on their own through -their computer or app or through a doctor while they are on-site at the -hospital.

    • -

  • Deployment of affected system: 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 is less -straightforward than Exploitation. The option open is clearly ruled out. However, -it is not clear whether the optional Bluetooth connection between the -medical device and a phone app represents controlled or small 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. 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. 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 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 is complex, with many MEFs. However, even from -this abstract, it seems clear that “do no harm” is at risk due to this -vulnerability. A mission essential function to that mission is each of -the various medical devices works as expected, or at least if a device -fails, it cannot actively be used to inflict harm. Unsolicited insulin -delivery would mean that MEF “fails for a period of time longer than -acceptable,” matching the 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 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, and Automatable -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:

-
    -
  • Use of the cyber-physical system: Insulin pumps are -used to regulate blood glucose levels in diabetics. Diabetes is -extremely common in the US. Misregulation of glucose can cause a variety -of problems. Minor misregulation causes confusion or difficulty -concentrating. Long-term minor mismanagement causes weigh management -issues and blindness. Severe acute mismanagement can lead -unconsciousness in a matter of minutes and death in a matter of hours. -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 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 could -be catastrophic. 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. The pilot information -is inadequate in this regard, which is the likely source of disagreement -about Safety Impact in Table 13. -For the purposes of this example, imagine that after gathering that -information, the monitoring situation is adequate, and select hazardous. Therefore, mitigate this -vulnerability out-of-cycle, meaning that it should be addressed -quickly, ahead of the usual update and patch cycle.

-

Related Vulnerability -Management Systems

-

There are several other bodies of work that are used in practice to -assist vulnerability managers in making decisions. Three relevant -systems are CVSS (CVSS SIG -2019), EPSS (Jacobs et al. 2021), and Tenable's -Vulnerability Priority Rating (VPR). -There are other systems derived from CVSS, such as RVSS for robots (Vilches et al. -2018) and MITRE's effort to adapt CVSS to medical devices (Chase and Coley -2019). There are also other nascent efforts to automate aspects -of the decision making process, such as vPrioritizer. This -section discusses the relationship between these various systems and -SSVC.

-

CVSS

-

CVSS version 3.1 has three metric groups: base, environmental, and -temporal. The metrics in the base group are all required, and are the -only required metrics. In connection with this design, CVSS base scores -and base metrics are far and away the most commonly used and -communicated. A CVSS base score has two parts: the exploitability -metrics and the impact metrics. Each of these are echoed or reflected in -aspects of SSVC, though the breadth of topics considered by SSVC is -wider than CVSS version 3.1.

-

How CVSS is used matters. Using just the base scores, which are “the -intrinsic characteristics of a vulnerability that are constant over time -and across user environments,” as a stand-alone prioritization method is -not recommended (CVSS SIG -2019). Two examples of this include the U.S. government (see -Scarfone et al. 2008, 7–4; Souppaya and Scarfone 2013, 4; and -Cybersecurity and Infrastructure Security Agency 2015) and the -global payment card industry (PCI Security Standards Council 2017) -where both have defined such misuse as expected practice in their -vulnerability management requirements. CVSS scores have a complex -relationship with patch deployment in situations where it is not -mandated, at least in an ICS context (Wang et al. 2017).

-

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 (Chase and Coley 2019), robotics -(Vilches et al. -2018), and industrial systems (Figueroa-Lorenzo, Añorga, and -Arrizabalaga 2020). 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, Microsoft, -and Cisco. -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 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 decision point. Attack Complexity -may influence how long it may take an adversary to craft an automated -exploit, but Automatability 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 is written to just -consider firm barriers to automation.

-

Automatability includes -considerations that are not included in the exploitability metrics. Most -notably the concept of vulnerability chaining is addressed in Automatability but not addressed -anywhere in CVSS. Automatability -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.

-
-

Impact metrics (Base metric group)

-
-

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.

-

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 SIG 2019). 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, public and situated -Well-being Impact, 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 section.

-
-

Temporal metric groups

-
-

The temporal metric group primarily contains the Exploit Code -Maturity metric. This metric expresses a concept similar to Exploitation. The main difference is -that 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 (Householder, -Chrabaszcz, et al. 2020) and are not actively exploited Jacobs et al. -(2021).

-
-

Environmental metric group

-
-

The environmental metric group allows a consumer of a CVSS base score -to change it based on their environment. CVSS needs this functionality -because the organizations that produce CVSS scores tend to be what SSVC -calls suppliers and consumers of CVSS scores are what -SSVC calls deployers. These two stakeholder groups have -a variety of natural differences, which is why SSVC treats them -separately. SSVC does not have such customization as a bolt-on optional -metric group because SSVC is stakeholder-specific by design.

-

EPSS

-

The Exploit Prediction Scoring -System (EPSS) is “a data-driven effort for estimating the likelihood -(probability) that a software vulnerability will be exploited in the -wild.” EPSS is currently based on a machine-learning classifier and -proprietary data from Fortiguard, Alienvault OTX, the Shadowserver -Foundation and GreyNoise. 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 (Jonathan M. Spring et al. -2019). The use of proprietary training data makes the system less -transparent.

-

EPSS could be used to inform the Exploitation decision point. -Currently, 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 to active. A sufficiently high EPSS score -could therefore be used as an additional criterion for scoring a -vulnerability as active 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.” Just as 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 if EPSS were added to Exploitation.

-

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.

-

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 explains how stakeholders or stakeholder -communities can adapt SSVC in a reliable way that still promotes -repeatability and communication.

-

vPrioritizer

-

vPrioritizer is an open-source project that attempts to integrate -asset management and vulnerablity prioritization. The software is mostly -the asset management aspects. It currently includes CVSS base scores as -the de facto vulnerability prioritization method; however, fundamentally -the system is agnostic to prioritization method. vPrioritizer is an -example of a product that is closely associated with vulnerability -prioritization, but is not directly about the prioritization method. 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 and situated Well-being Impact, but it does -not have a ready expression in CVSS, EPSS, or VPR.

-

SSVC using Current -Information Sources

-

Some SSVC decision points can be informed or answered by currently -available information feeds or sources. These include Exploitation, System Exposure, Technical Impact, and Public Safety Impact. 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. These sections provide -suggestions that would also contribute to creating or honing information -feeds. However, if there is a category of information source we have not -captured, please create an issue on the SSVC GitHub -page explaining it and what decision point it informs.

-

Various vendors provide paid feeds of vulnerabilities that are -currently exploited by attacker groups. Any of these could be used to -indicate that active 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 (Metcalf and Spring 2015) and -malware (Kührer, -Rossow, and Holz 2014). 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.

-

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 if such a general purpose -Internet scan finds that the service responds. Such scans do not find -all open systems, but any system -they find should be considered open. 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 if, say, the scan finds -them on an internal network where devices regularly connect to the -Internet.

-

Some information sources that were not designed with SSVC in mind can -be adapted to work with it. Three prominent examples are CVSS impact -base metrics, CWE, and CPE.

-

Technical Impact is directly -related to the CVSS impact metric group. However, this metric group -cannot be directly mapped to Technical -Impact in CVSS version 3 because of the Scope metric. Technical Impact 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 is total, 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 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 SIG 2019). 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 because as a result of the -exploit the attacker gains total control of the device, even though they -started with partial control.

-

As mentioned in the discussion of Exploitation, CWE could be used to inform one of the -conditions that satisfy proof of -concept. 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 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. 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 could be determined -almost entirely from available information without direct analyst -involvement at each organization.

-

CPE could possibly -be curated into a list of representative Public Safety Impact values -for each platform or product. The Situated Safety Impact would -be too specific for a classification as broad as CPE. But it might work -for 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 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 based on -the platforms that the supplier needs information about most often.

-

Potential Future Information -Feeds

-

So far, we have identified information sources that can support -scalable decision making for most decision points. Some sources, such as -CWE or existing asset management solutions, would require a little bit -of connective glue to support SSVC, but not too much. The SSVC decision -point that we have not identified an information source for is Utility. Utility is composed of Automatable and Value Density, 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 and Value Density 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 and Value Density. 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 and Value Density. 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 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.

-

Future Work

-

We intend SSVC to offer a workable baseline from which to improve and -refine a vulnerability-prioritization methodology. We are working to -improve SSVC. Several of the future work items in this section have -issues associated with them on the SSVC GitHub page (https://github.com/CERTCC/SSVC/issues), which is a good -place to go to check on progress or help. Plans for future work focus on -further requirements gathering, analysis of types of risk, and further -testing of the reliability of the decision process.

-

Requirements -Gathering via Sociological Research

-

The community should know what users of a vulnerability -prioritization system want. To explore their needs, it is important to -understand how people actually use CVSS and what they think it tells -them. In general, such empirical, grounded evidence about what -practitioners and decision makers want from vulnerability scoring is -lacking. We have based this paper’s methodology on multiple decades of -professional experience and myriad informal conversations with -practitioners. Such evidence is not a bad place to start, but it does -not lend itself to examination and validation by others. The purpose of -understanding practitioner expectations is to inform what a -vulnerability-prioritization methodology should actually provide by -matching it to what people want or expect. The method this future work -should take is long-form, structured interviews. We do not expect anyone -to have access to enough consumers of CVSS to get statistically valid -results out of a short survey, nor to pilot a long survey.

-

Coordinators in particular are likely to be heterogeneous. While the -FIRST service frameworks for PSIRTs and CSIRTs differentiate two broad -classes of coordinators, we have focused on CSIRTs here. PSIRTs may have -somewhat different concerns. Investigating the extent to which SSVC -should be customized for this group is future work as well.

-

Types of Risks

-

SSVC estimates the relative risk created by a vulnerability in an -information system. The priority of acting to mitigate or remediate a -vulnerability goes up as this vulnerability risk goes up. SSVC does not -currently take into account the change risk due to applying a mitigation -or remediation.

-

One way to view what SSVC currently provides is that it tells you how -urgently a stakeholder should analyze overall risk due to a -vulnerability. 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 relative to vulnerability risk.

-

Tree -Construction and Customization Guidance 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 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. How exactly to aggregate these -different effects is not currently specified except to say that the unit -of analysis is the whole work item. Future work should provide some -examples of how this holistic analysis of multiple vulnerabilities -remediated in one patch should be conducted.

-

Further Decision Tree -Testing

-

More testing with diverse analysts is necessary before the decision -trees are reliable. In this context, reliable means -that two analysts, given the same vulnerability description and decision -process description, will reach the same decision. Such reliability is -important if scores and priorities are going to be useful. If they are -not reliable, they will vary widely over time and among analysts. Such -variability makes it impossible to tell whether a difference in scores -is really due to one vulnerability being higher priority than other.

-

The SSVC version 1 pilot study provides a methodology for measuring -and evaluating reliability of the decision process description based on -the agreement measure k. This study methodology should be -repeated with different analyst groups, from different sectors and with -different experience, using the results to make changes in the decision -process description until the agreement measure is adequately close to -1.

-

Internationalization and localization of SSVC will also need to be -considered and tested in future work. It is not clear how best to -consider translating SSVC decision points, if at all. And at a very practical -level, the Abbreviated Format -would have to define a new algorithm for creating initialisms that is -not dependent an an alphabet for languages based on syllabaries or -ideograms. But a more actionable item of future work would be to include -non-native English speakers in future usability studies.

-

A different approach to testing the Utility decision point could be based on Alternative Utility Outputs. -Namely, future work could example exploit resale markets and compare the -value of exploits to the Utility 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 -is reasonable.

-

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.

-

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. While these are inherently -limitations of SSVC, we do not intend SSVC to be the one and only -vulnerability management tool available. Those for whom these -limitations are a must-have may be better supported by a different -vulnerability management framework.

-
    -

  1. We eliminated numerical scores; this may make some practitioners -uncomfortable. We explained the reasons for this in depth, but even -though CVSS contains false precision, we still must contend with the -fact that, psychologically, users find that comforting. As this comfort -gap may negatively impact adoption, this fact is a limitation. Although -it is ungainly, it would be sound to convert the priority outcomes to -numbers at the end of the process, if existing processes require it. -Which numbers we choose to convert to is immaterial, as long as the -ordering is preserved. CVSS has set a precedent that higher numbers are -worse, so a scale [1, 2, 3, 4] would work, with defer = 1 and -immediate = 4. However, if it were important to maintain -backwards compatibility to the CVSS range zero to ten, we could just as -well relabel outcomes as [2, 5.5, 8, 9.5] for the midpoints of the -current CVSS severity ranges. This is not a calculation of any kind, -just an assignment of a label which may make adoption more conventient. -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.

    2. -

  2. We incorporated a wider variety of inputs from contexts beyond -the affected component. Some organizations are not prepared or -configured to reliably produce such data (e.g., around mission impact or -safety impact). There is adequate guidance for how to elicit and curate -this type information from various risk management frameworks, including -OCTAVE (Caralli et -al. 2007). Not every organization is going to have sufficiently -mature risk management functions to apply SSVC. -This second limitation should be approached with two strategies:

    -
      -
    1. Organizations should be encouraged and enabled to mature their risk -management capabilities
      2. -
    2. In the meantime, organizations such as NIST could consider -developing default advice. The most practical framing of this approach -might be for the NIST NVD to produce scores from the perspective of a -new stakeholder—something like “national security” or “public -well-being” that is explicitly a sort of default advice for otherwise -uninformed organizations that can then explicitly account for national -priorities, such as critical infrastructure.
      3. -
    3. -
-

Conclusion

-

SSVC version 2 presents a method for suppliers, deployers, and -coordinators to use to prioritize their effort to mitigate -vulnerabilities. We have built on SSVC version 1 through public -presentation and feedback, private consultation, and continued analyst -testing. The evaluation process we developed in version 1 remains an -important part of continued improvement of SSVC, and will be used to -continue refinements of SSVC version 2. We invite participation and -further refinement of the prioritization mechanism from the community as -well, such as by posting -an issue. We endeavored to be transparent about our process and -provide justification for design decisions.

-

We invite questions, comments, and further community refinement in -moving forward with a transparent and justified vulnerability -prioritization methodology that is inclusive for the various -stakeholders and industries that develop and use information and -computer technology.

-

Acknowledgements

-

The authors would first like to acknowledge the valuable -contributions of previous authors who have worked on earlier versions of -this report: Art Manion, Madison Oliver, and Deana Shick.

-

The authors thank the contributors -to the SSVC project on -Github as well as the following individuals for helpful comments on -prior drafts (listed in alphabetical order): Muhammad Akbar, Will -Dormann, Manish Gaur, Ralph Langer, David Oxley Dale Peterson, Jeroen -van der Ham, Michel van Eeten, and Sounil Yu.

-

The authors also thank those others too numerous to name individually -who provided comments and feedback, including: Attendees at S4, Miami FL -2020; Attendees at A Conference on Defense (ACoD), Austin TX 2020; -Anonymous WEIS reviewers; Various staff members and analysts at CERT/CC, -CISA, McAfee, and VMWare; FIRST CVSS SIG and EPSS SIG members; and -others who wish to remain anonymous.

-

Contact Us

-

Software Engineering Institute
-4500 Fifth Avenue, Pittsburgh, PA 15213-2612

-

Phone: 412.268.5800 | 888.201.4479
-Web: www.sei.cmu.edu
-Email:

-

Copyright

-

Copyright 2019-2023 Carnegie Mellon University.

-

This material is based upon work funded and supported by the -Department of Defense under Contract No. FA8702-15-D-0002 with Carnegie -Mellon University for the operation of the Software Engineering -Institute, a federally funded research and development center.

-

The view, opinions, and/or findings contained in this material are -those of the author(s) and should not be construed as an official -Government position, policy, or decision, unless designated by other -documentation.

-

References herein to any specific commercial product, process, or -service by trade name, trade mark, manufacturer, or otherwise, does not -necessarily constitute or imply its endorsement, recommendation, or -favoring by Carnegie Mellon University or its Software Engineering -Institute.

-

NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING -INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON -UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, -AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR -PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF -THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF -ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT -INFRINGEMENT.

-

[DISTRIBUTION STATEMENT A] This material has been approved for public -release and unlimited distribution. Please see Copyright notice for -non-US Government use and distribution.

-

Internal use:* Permission to reproduce this material and to prepare -derivative works from this material for internal use is granted, -provided the copyright and “No Warranty” statements are included with -all reproductions and derivative works.

-

External use:* This material may be reproduced in its entirety, -without modification, and freely distributed in written or electronic -form without requesting formal permission. Permission is required for -any other external and/or commercial use. Requests for permission should -be directed to the Software Engineering Institute at .

-

* These restrictions do not apply to U.S. government entities.

-

Carnegie Mellon®, CERT Coordination Center® and OCTAVE® are -registered in the U.S. Patent and Trademark Office by Carnegie Mellon -University.

-

DM19-1222

-
-
-Akbar, Muhammad. 2020. “A Critical First Look at Stakeholder -Specific Vulnerability Categorization (SSVC).” March 6, 2020. https://blog.secursive.com/posts/critical-look-stakeholder-specific-vulnerability-categorization-ssvc/. -
-
-Allodi, Luca, Marco Cremonini, Fabio Massacci, and Woohyun Shim. 2018. -“The Effect of Security Education and Expertise on Security -Assessments: The Case of Software Vulnerabilities.” In -Workshop on Economics of Information Security. Innsbruck, -Austria. -
-
-Allodi, Luca, and Fabio Massacci. 2012. “A Preliminary Analysis of -Vulnerability Scores for Attacks in Wild: The EKITS and SYM -Datasets.” In Workshop on Building Analysis Datasets and -Gathering Experience Returns for Security, 17–24. ACM. -
-
-Bano, Shehar, Philipp Richter, Mobin Javed, Srikanth Sundaresan, Zakir -Durumeric, Steven J Murdoch, Richard Mortier, and Vern Paxson. 2018. -“Scanning the Internet for Liveness.” SIGCOMM Computer -Communication Review 48 (2): 2–9. -
-
-Benetis, Vilius, Olivier Caleff, Cristine Hoepers, Angela Horneman, -Allen Householder, Klaus-Peter Kossakowski, Art Manion, et al. 2019. -“Computer Security Incident Response Team (CSIRT) -Services Framework.” ver. 2. Cary, NC, USA: FIRST. -
-
-Captera. 2019. “IT Asset Management Software.” 2019. https://www.capterra.com/it-asset-management-software/. -
-
-Caralli, Richard, James Stevens, Lisa Young, and William Wilson. 2007. -“Introducing OCTAVE Allegro: Improving the -Information Security Risk Assessment Process.” -CMU/SEI-2007-TR-012. Pittsburgh, PA: Software Engineering Institute, -Carnegie Mellon University. https://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=8419. -
-
-Cebula, James L, and Lisa R Young. 2010. “A Taxonomy of -Operational Cyber Security Risks.” CMU/SEI-2010-TN-028. -Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon -University. https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9395. -
-
-Chase, Melissa P, and Steven M Cristey Coley. 2019. “Rubric for -Applying CVSS to Medical Devices.” 18-2208. McLean, VA, USA: -MITRE Corporation. https://www.mitre.org/publications/technical-papers/rubric-for-applying-cvss-to-medical-devices. -
-
-Cichonski, Paul, Tom Millar, Tim Grance, and Karen Scarfone. 2012. -“Computer Security Incident Handling Guide.” SP 800-61r2. -Gaithersburg, MD: US Dept of Commerce, National Institute -of Standards; Technology. -
-
-CVE Board. 2020. “CVE Numbering Authority -(CNA) Rules.” ver. 3.0. Bedford, MA: MITRE. https://cve.mitre.org/cve/cna/rules.html. -
-
-CVSS SIG. 2019. “Common Vulnerability Scoring System.” -version 3.1 r1. Cary, NC, USA: Forum of Incident Response; Security -Teams. https://www.first.org/cvss/v3.1/specification-document. -
-
-Cybersecurity and Infrastructure Security Agency. 2015. “Critical -Vulnerability Mitigation.” May 21, 2015. https://cyber.dhs.gov/bod/15-01/. -
-
-“DoD Directive 3020.26 DoD Continuity Policy.” 2018. US -Department of Defense. https://github.com/CERTCC/SSVC/pull/281/commits/791dcabd716c2e681215493b26cba79f3863887b. -
-
-FAA. 2000. “System Safety Handbook.” Washington, DC: US -Dept. of Transportation, Federal Aviation Administration. https://www.faa.gov/regulations_policies/handbooks_manuals/aviation/risk_management/ss_handbook/. -
-
-Falotico, Rosa, and Piero Quatto. 2015. “Fleiss’ Kappa Statistic -Without Paradoxes.” Quality & Quantity 49 (2): -463–70. -
-
-Farris, Katheryn A, Ankit Shah, George Cybenko, Rajesh Ganesan, and -Sushil Jajodia. 2018. “VULCON: A System for Vulnerability -Prioritization, Mitigation, and Management.” Transactions on -Privacy and Security 21 (4): 16. -
-
-Fenton, Robert J., ed. 2017. “Federal Continuity Directive 2: -Federal Executive Branch Mission Essential Functions and Candidate -Primary Mission Essential Functions Identification and Submission -Process.” US Department of Homeland Security, Federal Emergency -Management Agency. https://www.fema.gov/media-library-data/1499702987348-c8eb5e5746bfc5a7a3cb954039df7fc2/FCD-2June132017.pdf. -
-
-Figueroa-Lorenzo, Santiago, Javier Añorga, and Saioa Arrizabalaga. 2020. -“A Survey of IIoT Protocols: A Measure of -Vulnerability Risk Analysis Based on CVSS.” ACM Comput. -Surv. 53 (2). https://doi.org/10.1145/3381038. -
-
-Fleiss, Joseph L, and Jacob Cohen. 1973. “The Equivalence of -Weighted Kappa and the Intraclass Correlation Coefficient as Measures of -Reliability.” Educational and Psychological Measurement -33 (3): 613–19. -
-
-Garfinkel, Simson, and Heather Richter Lipford. 2014. “Usable -Security: History, Themes, and Challenges.” Synthesis -Lectures on Information Security, Privacy, and Trust 5 (2): 1–124. -
-
-Guido, Dan. 2011. “The Exploit Intelligence Project.” iSEC -Partners. http://www.trailofbits.com/resources/exploit_intelligence_project_2_slides.pdf. -
-
-Householder, Allen D, Jeff Chrabaszcz, Trent Novelly, David Warren, and -Jonathan M Spring. 2020. “Historical Analysis of Exploit -Availability Timelines.” In Workshop on Cyber Security -Experimentation and Test. Virtual conference: USENIX. -
-
-Householder, Allen D, Garret Wassermann, Art Manion, and Christopher -King. 2020. “The CERT Guide to Coordinated -Vulnerability Disclosure.” CMU/SEI-2017-TR-022. Pittsburgh, PA: -Software Engineering Institute, Carnegie Mellon University. https://vuls.cert.org/confluence/display/CVD/Executive+Summary. -
-
-Howard, Ronald A, and James E Matheson, eds. 1983. Readings on the -Principles and Applications of Decision Analysis: General -Collection. Vol. 1. Strategic Decisions Group. -
-
-Hutchins, Eric M, Michael J Cloppert, and Rohan M Amin. 2011. -“Intelligence-Driven Computer Network Defense Informed by Analysis -of Adversary Campaigns and Intrusion Kill Chains.” Leading -Issues in Information Warfare & Security Research 1: 80. -
-
-ISO. 2009. “Risk Management – Vocabulary.” 73:2009(en). -Geneva, CH: International Organization for Standardization. https://www.iso.org/obp/ui/#iso:std:iso:guide:73:ed-1:v1:en. -
-
-Jacobs, Jay, Sasha Romanosky, Benjamin Edwards, Idris Adjerid, and -Michael Roytman. 2021. “Exploit Prediction Scoring System -(EPSS).” Digital Threats 2 (3). https://doi.org/10.1145/3436242. -
-
-Jump, Michelle, and Art Manion. 2019. “Framing Software Component -Transparency: Establishing a Common Software Bill of -Material (SBOM).” Washington, DC: National -Telecommunications; Information Administration. -
-
-Kührer, Marc, Christian Rossow, and Thorsten Holz. 2014. “Paint It -Black: Evaluating the Effectiveness of Malware Blacklists.” In -Recent Advances in Intrusion Detection, 1–21. LNCS 8688. -Gothenburg, Sweden: Springer. -
-
-Laube, Stefan, and Rainer Böhme. 2017. “Strategic Aspects of Cyber -Risk Information Sharing.” ACM Comput. Surv. 50 (5). https://doi.org/10.1145/3124398. -
-
-Manion, Art, Kazuya Togashi, Joseph B. Kadane, Fumihiko Kousaka, Shawn -McCaffrey, Christopher King, Masanori Yamaguchi, and Robert Weiland. -2009. “Effectiveness of the Vulnerability Response Decision -Assistance (VRDA) Framework.” Pittsburgh, PA: -Software Engineering Institute, Carnegie Mellon University. https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=50301. -
-
-Metcalf, Leigh B, and Jonathan M Spring. 2015. “Blacklist -Ecosystem Analysis: Spanning Jan 2012 to Jun -2014.” In Workshop on Information Sharing and Collaborative -Security, 13–22. Denver: ACM. -
-
-Office of the DoD Chief Information Officer. 2020. “DoD -Instruction 8531.01 DoD Vulnerability Management.” Washington, -DC: Department of Defense. https://fas.org/irp/doddir/dod/i8531_01.pdf. -
-
-PCI Security Standards Council. 2017. “Payment Card Industry (PCI) -Data Security Standard: Approved Scanning Vendors.” ver 3.0. -Wakefield, MA, USA. https://www.pcisecuritystandards.org/documents/ASV_Program_Guide_v3.0.pdf. -
-
-Pedregosa, F., G. Varoquaux, A. Gramfort, V. Michel, B. Thirion, O. -Grisel, M. Blondel, et al. 2011. “Scikit-Learn: Machine Learning -in Python.” Journal of Machine Learning -Research 12: 2825–30. -
-
-Pendleton, Marcus, Richard Garcia-Lebron, Jin-Hee Cho, and Shouhuai Xu. -2016. “A Survey on Systems Security Metrics.” ACM -Comput. Surv. 49 (4): 62:1–35. -
-
-“Review of Human Decision-Making During Computer Security Incident -Analysis.” 2021. Digital Threats: Research and Practice -2 (2). https://doi.org/10.1145/3427787. -
-
-RTCA, Inc. 2012. “Software Considerations in Airborne Systems and -Equipment Certification.” DO-178C. Washington, DC: EUROCAE WG-12. -
-
-Russell, Stuart J, and Peter Norvig. 2011. Artificial Intelligence: -A Modern Approach. 3rd ed. Upper Saddle River, NJ: Pearson -Education. -
-
-Scarfone, Karen, Murugiah Souppaya, Amanda Cody, and Angela Orebaugh. -2008. “Technical Guide to Information Security Testing and -Assessment.” SP 800-115. Gaithersburg, MD: US Dept of Commerce, -National Institute of Standards; Technology. -
-
-Simon, Herbert A. 1996. The Sciences of the Artificial. 3rd ed. -Cambridge, MA: MIT press. -
-
-Souppaya, Muragiah, and Karen Scarfone. 2013. “Guide to Enterprise -Patch Management Technologies.” SP 800-40r3. Gaithersburg, MD: US -Dept of Commerce, National Institute of Standards; Technology. -
-
-Spring, Jonathan M., Joshua Fallon, April Galyardt, Angela Horneman, -Leigh Metcalf, and Ed Stoner. 2019. “Machine Learning in -Cybersecurity: A Guide.” CMU/SEI-2019-TR-005. Pittsburgh, PA: -Software Engineering Institute, Carnegie Mellon University. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=633583. -
-
-Spring, Jonathan M, Eric Hatleback, Allen D Householder, Art Manion, and -Deana Shick. 2018. “Towards Improving CVSS.” -Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon -University. -
-
-Spring, Jonathan M, and Phyllis Illari. 2018. “Building General -Knowledge of Mechanisms in Information Security.” Philosophy -& Technology 32 (September): 627–59. https://doi.org/10.1007/s13347-018-0329-z. -
-
-Spring, Jonathan M, Sarah Kern, and Alec Summers. 2015. “Global -Adversarial Capability Modeling.” In APWG Symposium on -Electronic Crime Research (eCrime). Barcelona: IEEE. -
-
-Spring, Jonathan M, Tyler Moore, and David Pym. 2017. “Practicing -a Science of Security: A Philosophy of Science Perspective.” In -New Security Paradigms Workshop. Santa Cruz, CA, USA. https://tylermoore.utulsa.edu/nspw17.pdf. -
-
-Tucker, Brett. 2018. “OCTAVE FORTE and FAIR Connect Cyber Risk -Practitioners with the Boardroom.” June 2018. https://insights.sei.cmu.edu/insider-threat/2018/06/octave-forte-and-fair-connect-cyber-risk-practitioners-with-the-boardroom.html. -
-
-Vilches, Vı́ctor Mayoral, Endika Gil-Uriarte, Irati Zamalloa Ugarte, -Gorka Olalde Mendia, Rodrigo Izquierdo Pisón, Laura Alzola Kirschgens, -Asier Bilbao Calvo, Alejandro Hernández Cordero, Lucas Apa, and César -Cerrudo. 2018. “Towards an Open Standard for Assessing the -Severity of Robot Security Vulnerabilities, the Robot Vulnerability -Scoring System (RVSS).” arXiv Preprint -arXiv:1807.10357. -
-
-Wang, Brandon, Xiaoye Li, Leandro P de Aguiar, Daniel S Menasche, and -Zubair Shafiq. 2017. “Characterizing and Modeling Patching -Practices of Industrial Control Systems.” Measurement and -Analysis of Computing Systems 1 (1): 1–23. -
-
-Wiles, Darius, and Dave Dugal, eds. 2019. “Common Vulnerability -Scoring System SIG.” FIRST. 2019. https://www.first.org/cvss/. -
-
- - diff --git a/draft/ssvc.pdf b/pdfs/ssvc_2_1_draft.pdf similarity index 100% rename from draft/ssvc.pdf rename to pdfs/ssvc_2_1_draft.pdf From 39dae4f72abbd9c355c0519f19a9283704c0bef6 Mon Sep 17 00:00:00 2001 From: ccullen-cert <145690209+ccullen-cert@users.noreply.github.com> Date: Fri, 8 Mar 2024 09:35:16 -0500 Subject: [PATCH 109/113] Remove WIP disclaimer from home page (#507) * Update index.md * Update items_with_same_priority.md * Update items_with_same_priority.md --- docs/index.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/docs/index.md b/docs/index.md index 1dbe5e16..c6faf6d3 100644 --- a/docs/index.md +++ b/docs/index.md @@ -5,14 +5,6 @@ It is a methodology for prioritizing vulnerabilities based on the needs of the s SSVC is designed to be used by any stakeholder in the vulnerability management process, including finders, vendors, coordinators, deployers, and others. - -{== TODO remove this warning when the site is ready ==} -!!! warning "Work in Progress" - - This website is a work in progress. - While it is intended to eventually be the official documentation for SSVC, it is not yet complete. - For the latest version of SSVC documentation, see the [GitHub repository](https://github.com/CERTCC/SSVC). - ## Where to go from here We have organized the SSVC documentation into four main sections: From 4f0ba5c30b20d291a6d6a100bc78bb608dc2fa56 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 8 Mar 2024 09:47:18 -0500 Subject: [PATCH 110/113] fixes #531 --- CONTRIBUTING.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8838e46d..d3e01067 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -8,8 +8,7 @@ for more information on how you can contribute to the project. ## Licenses - - The license for all code in the repository is [here](https://github.com/CERTCC/SSVC/blob/main/LICENSE) - - The license for all English writing in the repository is [here](https://github.com/CERTCC/SSVC/blob/main/doc/version_1/900_license.md) +See [LICENSE](https://github.com/CERTCC/SSVC/blob/main/LICENSE) ## Questions From 958d127766ed9cc42b4e6b1e7d0f1d7913d3bd7f Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 8 Mar 2024 09:49:07 -0500 Subject: [PATCH 111/113] change intro line in to LICENSE --- LICENSE | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/LICENSE b/LICENSE index e97348e2..c5d2a6ad 100644 --- a/LICENSE +++ b/LICENSE @@ -24,8 +24,7 @@ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ---- -The following statement applies to documents contained in this repository, and can also be found in each -individual document. +The following statement applies to PDF, markdown, and text documents contained in this repository. This material is based upon work funded and supported by the Department of Defense under Contract No. FA8702-15-D-0002 with Carnegie Mellon University for the operation From d5f68d660d371b80a87c5da03825d2de8fdc8315 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Fri, 8 Mar 2024 12:17:41 -0500 Subject: [PATCH 112/113] Set up static site deploy from publish branch (#533) --- .github/workflows/deploy_site.yml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/.github/workflows/deploy_site.yml b/.github/workflows/deploy_site.yml index 38eee085..2c135e98 100644 --- a/.github/workflows/deploy_site.yml +++ b/.github/workflows/deploy_site.yml @@ -5,9 +5,10 @@ on: # Allows you to run this workflow manually from the Actions tab workflow_dispatch: - # Runs on pushes targeting the default branch + # Runs on pushes targeting specific branch(es) push: - branches: [main, staging] + branches: + - publish # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages From 07d0e2cc1dbb283f047157307aee87c211dee67f Mon Sep 17 00:00:00 2001 From: cgyarbrough <72204189+cgyarbrough@users.noreply.github.com> Date: Fri, 8 Mar 2024 12:38:58 -0500 Subject: [PATCH 113/113] Update enumerating_stakeholders.md (#535) * Update enumerating_stakeholders.md Line 30 replaced 'paper' with 'document' Line 26 replaced comment line. * remove highlight tags --------- Co-authored-by: Allen D. Householder --- docs/topics/enumerating_stakeholders.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/topics/enumerating_stakeholders.md b/docs/topics/enumerating_stakeholders.md index 5a7fc9b3..91adc98f 100644 --- a/docs/topics/enumerating_stakeholders.md +++ b/docs/topics/enumerating_stakeholders.md @@ -23,11 +23,11 @@ We can treat the responsibilities as non-overlapping, and, therefore, we can bui Each of these trees will have different decision points that they take to arrive at a decision about a given unit of work. -{== The next two sections describe the decision space and the relevant decision points that we propose for these two responsibilities within the vulnerability management process. ==} +In [Enumerating Decisions](./enumerating_decisions.md), we describe the decision space and the relevant decision points that we propose for these two responsibilities within the vulnerability management process. !!! info "Target Audience" - {== The target audience for this paper is professional staff responsible for making decisions about information systems. ==} + The target audience for this documentation is professional staff responsible for making decisions about information systems. This audience encompasses a broad class of professionals, including suppliers, system maintainers, and administrators of many types. It also includes other roles, such as risk managers, technical managers, and incident responders. Although every layperson who owns a computing device makes decisions about managing it, they are not the target audience.