diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 00000000..389d3b45 --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,33 @@ +# These rules follow a last-match behavior. + +# default (if nothing else matches) +* @ahouseholder @sei-vsarvepalli @cgyarbrough + +# any markdown file in doc +/doc/**/*.md @ahouseholder @cgyarbrough @sei-vsarvepalli @j--- + +# any markdown file in docs +/docs/**/*.md @ahouseholder @cgyarbrough @sei-vsarvepalli @j--- + +# architecture decision records +/docs/adr/*.md @ahouseholder @cgyarbrough @sei-vsarvepalli @j--- + +# ssvc-calc, wherever it lives +ssvc-calc/ @sei-vsarvepalli @ahouseholder + +# source code +/src/ @ahouseholder @sei-vsarvepalli +*.py @ahouseholder +*.js @sei-vsarvepalli + +# data +/data/ @sei-vsarvepalli @ahouseholder +/data/csvs @ahouseholder @j--- +/data/schema @sei-vsarvepalli +/data/schema_examples @sei-vsarvepalli + +# website config +mkdocs.yml @ahouseholder + +# github setup +/.github/ @ahouseholder @sei-vsarvepalli 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/.github/dependabot.yml b/.github/dependabot.yml new file mode 100644 index 00000000..1114502a --- /dev/null +++ b/.github/dependabot.yml @@ -0,0 +1,23 @@ +# To get started with Dependabot version updates, you'll need to specify which +# package ecosystems to update and where the package manifests are located. +# Please see the documentation for all configuration options: +# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates + +version: 2 +updates: + - package-ecosystem: "pip" # See documentation for possible values + directory: "/" # Location of package manifests + schedule: + interval: "weekly" + groups: + mkdocs: + patterns: + - "mkdocs*" + update-types: + - "minor" + - "patch" + - package-ecosystem: "github-actions" + directory: "/" + schedule: + interval: "weekly" + diff --git a/.github/workflows/deploy_site.yml b/.github/workflows/deploy_site.yml new file mode 100644 index 00000000..2c135e98 --- /dev/null +++ b/.github/workflows/deploy_site.yml @@ -0,0 +1,62 @@ +# 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 specific branch(es) + push: + branches: + - publish + + +# 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@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 + + - name: Setup Pages + uses: actions/configure-pages@v4 + + - name: Build Site + run: | + mkdocs build --verbose --clean --config-file mkdocs.yml + + - name: Upload artifact + uses: actions/upload-pages-artifact@v3 + with: + # Upload entire repository + path: 'site' + + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v4 diff --git a/.github/workflows/link_checker.yml b/.github/workflows/link_checker.yml new file mode 100644 index 00000000..6d0f83c7 --- /dev/null +++ b/.github/workflows/link_checker.yml @@ -0,0 +1,45 @@ +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 + - '**/*.md' + # run on any PR that changes this workflow + - .github/workflows/linkchecker.yml + # let us trigger it manually + workflow_dispatch: + +jobs: + linkcheck: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + + - name: Set up Python + uses: actions/setup-python@v5 + with: + python-version: '3.10' + + - name: Install dependencies + run: | + python -m pip install --upgrade pip + python -m pip install -r requirements.txt + python -m pip install linkchecker + + - name: Install our python stuff + run: | + python -m pip install -e src + + - name: Build Site + run: | + mkdocs build --verbose --clean --config-file mkdocs.yml + + - name: Check links + run: | + linkchecker site/index.html + diff --git a/.github/workflows/python-app.yml b/.github/workflows/python-app.yml new file mode 100644 index 00000000..ecbe9b4c --- /dev/null +++ b/.github/workflows/python-app.yml @@ -0,0 +1,45 @@ +# This workflow will install Python dependencies, run tests and lint with a single version of Python +# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python + +name: Python application + +on: + push: + branches: [ "main" ] + pull_request: + branches: [ "main" ] + +permissions: + contents: read + +jobs: + build: + + runs-on: ubuntu-latest + + steps: + - uses: actions/checkout@v4 + with: + fetch-tags: true + - name: Set up Python 3.10 + uses: actions/setup-python@v5 + with: + python-version: "3.10" + - name: Install dependencies + run: | + python -m pip install --upgrade pip + pip install pytest build + if [ -f requirements.txt ]; then pip install -r requirements.txt; fi +# - uses: psf/black@stable + - name: Test with pytest + run: | + pytest + - name: Build + run: | + python -m build src + - name: Upload Artifacts + uses: actions/upload-artifact@v4 + with: + name: ssvc + path: src/dist/ssvc-*.tar.gz + retention-days: 14 diff --git a/.gitignore b/.gitignore index 96a61d5e..6189a8e6 100644 --- a/.gitignore +++ b/.gitignore @@ -128,3 +128,4 @@ dmypy.json # Pyre type checker .pyre/ ssvc2-applier-wip.xlsx +_version.py diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b8ac128e..d3e01067 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,39 +1,17 @@ # How to contribute -Thanks for your help on improving our stakeholder-specific vulnerability categorization work. To account for different stakeholder perspectives, we benefit from a diverse group of contributors. +Thanks for your help on improving our stakeholder-specific vulnerability categorization work. +To account for different stakeholder perspectives, we benefit from a diverse group of contributors. -## Where to contribute +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. -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. +## Licenses -# Contributing to the document - -The English text lives in the `doc` [subfolder](https://github.com/CERTCC/SSVC/tree/main/doc). -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. -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+)) - -In the `doc` folder, please see the `style-guide`, `crossref-how-to`, and `reference-how-to` 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 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 - - - 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 +## Questions -If you have any questions, a message to j--- should work, or tweet @zmanion or @\_\_adh\_\_. +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/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 diff --git a/README.md b/README.md index 42e150a4..1b0cf593 100644 --- a/README.md +++ b/README.md @@ -1,64 +1,117 @@ -[![pandoc_html_pdf](https://github.com/CERTCC/SSVC/actions/workflows/pandoc_html_pdf.yaml/badge.svg)](https://github.com/CERTCC/SSVC/actions/workflows/pandoc_html_pdf.yaml) +[![Link Checker](https://github.com/CERTCC/SSVC/actions/workflows/link_checker.yml/badge.svg?branch=main)](https://github.com/CERTCC/SSVC/actions/workflows/link_checker.yml) # SSVC 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. -## `/doc/*` +**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. -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. +# What's here + +Here's a quick overview of the main directories and files in this repository. -## `/pdfs/*.pdf` +## `/docs/*` -Static versions of previously issued reports are stored in this directory. +Raw markdown and graphics files used to build the SSVC documentation website. +See [`project_docs/README.md`](project_docs/README.md) for more info. -## `/data/*.csv` +### `/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/ + +## `/pdfs/*` + +Static versions of previously issued PDF reports are stored in this directory. + +## `/data/*` 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. -Customizing the "outcome" column in this csv is the primary recommended way that stakehodlers might adapt SSVC to their environment. +There are both `.csv` and `.json` files in this directory. + +### `/data/csvs/*` + +The `.csv` files are the primary data files used by the `ssvc.py` module. + +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 stakeholders might adapt SSVC to their environment. + +### `/data/json/*` + +These json files are generated examples from the python `ssvc` module. -## `src/ssvc.py` +### `/data/schema/*` and `/data/schema_examples/*` -A basic Python module for interacting with the SSVC trees. `ssvc.py` has +These files are used by the `ssvc-calc` module. + +## `/src/*` + +This directory holds helper scripts that can make managing or using SSVC easier. + +### `/src/ssvc/*` + +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/) + +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. -## `ssvc-calc` -Directory with SSVC calculator using D3 graph. -See [`ssvc-calc/README.md`](ssvc-calc/README.md) for more info. +## Local development -A demo version of `ssvc-calc` can be found at https://certcc.github.io/SSVC/ssvc-calc/ +Install prerequisites: + +```bash +pip install -r requirements.txt +``` + +Start a local server: + +```bash +mkdocs serve +``` + +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:8000`) + +## Contributing + +- [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}, @@ -67,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/data/csvs/cwe/possible-cwe-with-poc-examples.csv b/data/csvs/cwe/possible-cwe-with-poc-examples.csv new file mode 100644 index 00000000..c8fdc97b --- /dev/null +++ b/data/csvs/cwe/possible-cwe-with-poc-examples.csv @@ -0,0 +1,157 @@ +CWE-ID,CWE name,In NVD's CWE Slice?,Possible PoC? ,How could vulnerabilities containing this CWE be exploited?,Tools,Links to tools +20,Improper Input Validation,yes,no,,, +22,Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'),yes,yes,"directory/path traversal ""../""",Panoptic; Burp Suite,https://github.com/lightos/Panoptic; https://portswigger.net/burp +59,Improper Link Resolution Before File Access ('Link Following'),yes,yes,symlink attack,No specialized resources are required to execute this type of attack. The only requirement is the ability to create the necessary symbolic link.,https://capec.mitre.org/data/definitions/132.html +73,External Control of File Name or Path,no,no,,, +74,Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'),yes,no,,, +77,Improper Neutralization of Special Elements used in a Command ('Command Injection'),yes,yes,command injection,Commix,https://github.com/commixproject/commix +78,Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'),yes,yes,OS command injection,Commix; Burp Suite,https://github.com/commixproject/commix; https://portswigger.net/burp +79,Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'),yes,yes,cross-site scripting attack,XSSER; Pybelt; XSStrike,https://github.com/epsylon/xsser; https://github.com/Ekultek/Pybelt; https://github.com/s0md3v/XSStrike +88,Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'),yes,yes,argument/parameter injection,Argument Injection Hammer,https://github.com/nccgroup/argumentinjectionhammer +89,Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'),yes,yes,malicious SQL command injection,SQLMap; BBQSQL; JSQL injection; NoSQLMap,https://github.com/sqlmapproject/sqlmap; https://github.com/CiscoCXSecurity/bbqsql; https://github.com/ron190/jsql-injection; https://github.com/codingo/NoSQLMap +91,XML Injection (aka Blind XPath Injection),yes,yes,"inject XML code into a web input, XML file or stream",XXExploiter,https://github.com/luisfontes19/xxexploiter +94,Improper Control of Generation of Code ('Code Injection'),yes,no,,, +115,Misinterpretation of Input,no,no,,, +116,Improper Encoding or Escaping of Output,yes,no,,, +119,Improper Restriction of Operations within the Bounds of a Memory Buffer,yes,no,,, +120,Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'),yes,no,,, +122,Heap-based Buffer Overflow,no,no,,, +125,Out-of-bounds Read,yes,no,,, +129,Improper Validation of Array Index,yes,no,,, +131,Incorrect Calculation of Buffer Size,yes,no,,, +134,Use of Externally-Controlled Format String,yes,no,,, +178,Improper Handling of Case Sensitivity,yes,no,,, +190,Integer Overflow or Wraparound,yes,no,,, +191,Integer Underflow (Wrap or Wraparound),yes,no,,, +193,Off-by-one Error,yes,no,,, +194,Unexpected Sign Extension,no,no,,, +200,Exposure of Sensitive Information to an Unauthorized Actor,yes,no,,, +201,Insertion of Sensitive Information Into Sent Data,no,no,,, +203,Observable Discrepancy,yes,no,,, +209,Generation of Error Message Containing Sensitive Information,yes,yes,read/capture sensitive information contained in error message,OWASP ZAP; Burp Suite,https://www.zaproxy.org/; https://portswigger.net/burp +212,Improper Removal of Sensitive Information Before Storage or Transfer,yes,no,,, +252,Unchecked Return Value,yes,no,,, +257,Storing Passwords in a Recoverable Format,no,no,,, +264,"Permissions, Privileges, and Access Controls",no,no,,, +269,Improper Privilege Management,yes,no,,, +273,Improper Check for Dropped Privileges,yes,no,,, +275,Permission Issues,no,no,,, +276,Incorrect Default Permissions,yes,yes,try to access data or privileges you normally should not have access to,"No specialized resources are required to execute this type of attack. In order to discover unrestricted resources, the attacker does not need special tools or skills. They only have to observe the resources or access mechanisms invoked as each action is performed and then try and access those access mechanisms directly.",https://capec.mitre.org/data/definitions/1.html +280,Improper Handling of Insufficient Permissions or Privileges,no,no,,, +281,Improper Preservation of Permissions,yes,no,,, +284,Improper Access Control,no,no,,, +287,Improper Authentication,yes,no,,, +290,Authentication Bypass by Spoofing,yes,no,,, +294,Authentication Bypass by Capture-replay,yes,yes,capture-replay attack,Wireshark; smartsniff,https://www.wireshark.org/; https://www.nirsoft.net/utils/smsniff.html +295,Improper Certificate Validation,yes,no,,, +305,Authentication Bypass by Primary Weakness,no,no,,, +306,Missing Authentication for Critical Function,yes,no,,, +307,Improper Restriction of Excessive Authentication Attempts,yes,yes,brute force attack,THC Hydra; John the Ripper; L0phtCrack; Hashcat,https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/ +311,Missing Encryption of Sensitive Data,yes,no,,, +312,Cleartext Storage of Sensitive Information,yes,yes,find sensitive data stored in system,OWASP ZAP; Burp Suite,https://www.zaproxy.org/; https://portswigger.net/burp +319,Cleartext Transmission of Sensitive Information,yes,yes,capture traffic and extract sensitive information,Wireshark; Smartsniff,https://www.wireshark.org/; https://www.nirsoft.net/utils/smsniff.html +321,Use of Hard-coded Cryptographic Key,no,no,,, +326,Inadequate Encryption Strength,yes,no,,, +327,Use of a Broken or Risky Cryptographic Algorithm,yes,no,,, +330,Use of Insufficiently Random Values,yes,yes,brute force attack,THC Hydra; John the Ripper; L0phtCrack; Hashcat,https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/ +331,Insufficient Entropy,yes,yes,brute force attack/predictive programs,hashcat; php_mt_seed,https://hashcat.net/hashcat/; https://github.com/openwall/php_mt_seed +335,Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG),yes,no,,, +337,Predictable Seed in Pseudo-Random Number Generator (PRNG),no,no,,, +338,Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG),yes,no,,, +345,Insufficient Verification of Data Authenticity,yes,no,,, +346,Origin Validation Error,yes,no,,, +347,Improper Verification of Cryptographic Signature,yes,no,,, +352,Cross-Site Request Forgery (CSRF),yes,yes,CSRF,Burp Suite; XSRFProbe,https://portswigger.net/burp; https://github.com/0xInfection/XSRFProbe +354,Improper Validation of Integrity Check Value,yes,no,,, +362,Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'),yes,no,,, +367,Time-of-check Time-of-use (TOCTOU) Race Condition,yes,no,,, +369,Divide By Zero,yes,no,,, +384,Session Fixation,yes,no,,, +388,7PK - Errors,no,no,,, +400,Uncontrolled Resource Consumption,yes,no,,, +401,Missing Release of Memory after Effective Lifetime,yes,no,,, +404,Improper Resource Shutdown or Release,yes,no,,, +405,Asymmetric Resource Consumption (Amplification),no,no,,, +407,Inefficient Algorithmic Complexity,yes,no,,, +415,Double Free,yes,no,,, +416,Use After Free,yes,no,,, +425,Direct Request ('Forced Browsing'),yes,yes,forcibly navigate to unintended (by the system) URLs,Dirbuster; Dirstalk,https://sourceforge.net/projects/dirbuster/; https://github.com/stefanoj3/dirstalk +426,Untrusted Search Path,yes,yes,malicious dll injection/loading,evildll; evilldll-gen,https://github.com/CrackerCat/evildll; https://gist.github.com/klezVirus/e24c94d7061f5736e2452eee022f4011 +427,Uncontrolled Search Path Element,yes,yes,malicious dll injection/loading,evildll; evilldll-gen,https://github.com/CrackerCat/evildll; https://gist.github.com/klezVirus/e24c94d7061f5736e2452eee022f4011 +428,Unquoted Search Path or Element,yes,yes,insert malicious input into unquoted search path,Metasploit,https://www.metasploit.com/ +434,Unrestricted Upload of File with Dangerous Type,yes,yes,uploading of malicious file (program lacks restrictions to prevent this from occuring),No specialized resources are required to execute this type of attack.,https://capec.mitre.org/data/definitions/1.html +436,Interpretation Conflict,yes,no,,, +441,Unintended Proxy or Intermediary ('Confused Deputy'),no,no,,, +444,Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling'),yes,yes,HTTP smuggling,Smuggler,https://github.com/defparam/smuggler +451,User Interface (UI) Misrepresentation of Critical Information,no,no,,, +459,Incomplete Cleanup,yes,no,,, +470,Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'),yes,no,,, +476,NULL Pointer Dereference,yes,no,,, +494,Download of Code Without Integrity Check,yes,no,,, +502,Deserialization of Untrusted Data,yes,no,,, +521,Weak Password Requirements,yes,yes,brute force attack,THC Hydra; John the Ripper; L0phtCrack; Hashcat,https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/ +522,Insufficiently Protected Credentials,yes,yes,"search for exposed credentials, capture traffic, or brute force (context-dependent)","Context-dependent, may utilize traffic sniffing tools, tools for discovering sensitive information, or brute forcing tools",https://www.wireshark.org/; https://www.nirsoft.net/utils/smsniff.html; https://www.zaproxy.org/; https://portswigger.net/burp; https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/ +532,Insertion of Sensitive Information into Log File,yes,yes,access log files and search them for sensitive information,OWASP ZAP; Burp Suite - along with the ability to access log files,https://www.zaproxy.org/; https://portswigger.net/burp +552,Files or Directories Accessible to External Parties,yes,no,,, +565,Reliance on Cookies without Validation and Integrity Checking,yes,no,,, +592,Authentication Bypass Issues,no,no,,, +601,URL Redirection to Untrusted Site ('Open Redirect'),yes,no,,, +602,Client-Side Enforcement of Server-Side Security,no,no,,, +610,Externally Controlled Reference to a Resource in Another Sphere,yes,no,,, +611,Improper Restriction of XML External Entity Reference,yes,yes,XML external entity injection,XXExploiter,https://github.com/luisfontes19/xxexploiter +613,Insufficient Session Expiration,yes,no,,, +617,Reachable Assertion,yes,no,,, +639,Authorization Bypass Through User-Controlled Key,yes,yes,"modify key values to change what data attacker has access to, insecure direct object vulnerability exploit",AuthZ for burpsuite,https://portswigger.net/bappstore/4316cc18ac5f434884b2089831c7d19e +640,Weak Password Recovery Mechanism for Forgotten Password,yes,no,,, +662,Improper Synchronization,yes,no,,, +665,Improper Initialization,yes,no,,, +667,Improper Locking,yes,no,,, +668,Exposure of Resource to Wrong Sphere,yes,no,,, +669,Incorrect Resource Transfer Between Spheres,yes,no,,, +670,Always-Incorrect Control Flow Implementation,yes,no,,, +672,Operation on a Resource after Expiration or Release,yes,no,,, +674,Uncontrolled Recursion,yes,no,,, +681,Incorrect Conversion between Numeric Types,yes,no,,, +682,Incorrect Calculation,yes,no,,, +697,Incorrect Comparison,yes,no,,, +703,Improper Check or Handling of Exceptional Conditions,no,no,,, +704,Incorrect Type Conversion or Cast,yes,no,,, +706,Use of Incorrectly-Resolved Name or Reference,yes,no,,, +732,Incorrect Permission Assignment for Critical Resource,yes,no,,, +749,Exposed Dangerous Method or Function,no,no,,, +754,Improper Check for Unusual or Exceptional Conditions,yes,no,,, +755,Improper Handling of Exceptional Conditions,yes,no,,, +759,Use of a One-Way Hash without a Salt,no,no,,, +763,Release of Invalid Pointer or Reference,yes,no,,, +770,Allocation of Resources Without Limits or Throttling,yes,no,,, +772,Missing Release of Resource after Effective Lifetime,yes,no,,, +776,Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion'),yes,yes,XML entity expansion,XXExploiter,https://github.com/luisfontes19/xxexploiter +787,Out-of-bounds Write,yes,no,,, +789,Memory Allocation with Excessive Size Value,no,no,,, +798,Use of Hard-coded Credentials,yes,yes,discover and use hardcoded credentials,"Context-dependent, may use password cracking tools, binary analysis tools, or may not require any tools (just knowledge of the default hard-coded credentials)",https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/; https://www.powergrep.com/ +823,Use of Out-of-range Pointer Offset,no,no,,, +824,Access of Uninitialized Pointer,yes,no,,, +829,Inclusion of Functionality from Untrusted Control Sphere,yes,no,,, +834,Excessive Iteration,yes,no,,, +835,Loop with Unreachable Exit Condition ('Infinite Loop'),yes,no,,, +838,Inappropriate Encoding for Output Context,yes,no,,, +843,Access of Resource Using Incompatible Type ('Type Confusion'),yes,no,,, +862,Missing Authorization,yes,no,,, +863,Incorrect Authorization,yes,no,,, +908,Use of Uninitialized Resource,yes,no,,, +909,Missing Initialization of Resource,yes,no,,, +913,Improper Control of Dynamically-Managed Code Resources,yes,no,,, +916,Use of Password Hash With Insufficient Computational Effort,yes,yes,brute force,THC Hydra; John the Ripper; L0phtCrack; Hashcat,https://github.com/vanhauser-thc/thc-hydra; https://github.com/openwall/john; https://gitlab.com/l0phtcrack/l0phtcrack; https://hashcat.net/hashcat/ +917,Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression La,yes,no,,, +918,Server-Side Request Forgery (SSRF),yes,yes,SSRF,SSRFmap; Burp Suite,https://github.com/swisskyrepo/SSRFmap; https://portswigger.net/web-security/ssrf +920,Improper Restriction of Power Consumption,yes,no,,, +922,Insecure Storage of Sensitive Information,yes,no,,, +924,Improper Enforcement of Message Integrity During Transmission in a Communication Channel,yes,no,,, +1021,Improper Restriction of Rendered UI Layers or Frames,yes,no,,, +1188,Insecure Default Initialization of Resource,yes,yes,use default credentials,"Context-dependent, but may not need any tools (for example, try to use default credentials or access resources that typically require permissions) - knowledge of the system (and its defaults) helps", +1236,Improper Neutralization of Formula Elements in a CSV File,yes,yes,CSV injection,"No specialized resources are required to execute this type of attack, it is more based on payloads.",https://gitlab.com/pentest-tools/PayloadsAllTheThings/-/tree/master/CSV%20Injection; https://owasp.org/www-community/attacks/CSV_Injection +1284,Improper Validation of Specified Quantity in Input,yes,no,,, +1321,Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'),yes,yes,prototype pollution,DOM Invader (Burp Suite),https://portswigger.net/burp/documentation/desktop/tools/dom-invader +1333,Inefficient Regular Expression Complexity,yes,yes,ReDoS or exponential backtracking,ReScue,https://2bdenny.github.io/ReScue/ +NVD-noinfo,There is insufficient information about the issue to classify it; details are unkown or unspecified.,yes,no,,, +NVD-Other,"NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.",yes,no,,, diff --git a/data/json/decision_points/automatable_2_0_0.json b/data/json/decision_points/automatable_2_0_0.json new file mode 100644 index 00000000..9a0369b2 --- /dev/null +++ b/data/json/decision_points/automatable_2_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "2.0.0", + "key": "A", + "name": "Automatable", + "description": "Can an attacker reliably automate creating exploitation events for this vulnerability?", + "values": [ + { + "key": "N", + "name": "No", + "description": "Attackers cannot reliably automate steps 1-4 of the kill chain for this vulnerability. These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation." + }, + { + "key": "Y", + "name": "Yes", + "description": "Attackers can reliably automate steps 1-4 of the kill chain." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/exploitation_1_0_0.json b/data/json/decision_points/exploitation_1_0_0.json new file mode 100644 index 00000000..9f287310 --- /dev/null +++ b/data/json/decision_points/exploitation_1_0_0.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "E", + "name": "Exploitation", + "description": "The present state of exploitation of the vulnerability.", + "values": [ + { + "key": "N", + "name": "None", + "description": "There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability." + }, + { + "key": "P", + "name": "PoC", + "description": "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." + }, + { + "key": "A", + "name": "Active", + "description": "Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/exploitation_1_1_0.json b/data/json/decision_points/exploitation_1_1_0.json new file mode 100644 index 00000000..bebf78a3 --- /dev/null +++ b/data/json/decision_points/exploitation_1_1_0.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.1.0", + "key": "E", + "name": "Exploitation", + "description": "The present state of exploitation of the vulnerability.", + "values": [ + { + "key": "N", + "name": "None", + "description": "There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability." + }, + { + "key": "P", + "name": "Public PoC", + "description": "One of the following is true: (1) Typical public PoC exists in sources such as Metasploit or websites like ExploitDB; or (2) the vulnerability has a well-known method of exploitation." + }, + { + "key": "A", + "name": "Active", + "description": "Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/human_impact_1_0_0.json b/data/json/decision_points/human_impact_1_0_0.json new file mode 100644 index 00000000..9d056efa --- /dev/null +++ b/data/json/decision_points/human_impact_1_0_0.json @@ -0,0 +1,29 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "HI", + "name": "Human Impact", + "description": "Human Impact is a combination of Safety and Mission impacts.", + "values": [ + { + "key": "L", + "name": "Low", + "description": "Safety Impact:(None OR Minor) AND Mission Impact:(None OR Degraded OR Crippled)" + }, + { + "key": "M", + "name": "Medium", + "description": "(Safety Impact:(None OR Minor) AND Mission Impact:MEF Failure) OR (Safety Impact:Major AND Mission Impact:(None OR Degraded OR Crippled))" + }, + { + "key": "H", + "name": "High", + "description": "(Safety Impact:Hazardous AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Major AND Mission Impact:MEF Failure)" + }, + { + "key": "VH", + "name": "Very High", + "description": "Safety Impact:Catastrophic OR Mission Impact:Mission Failure" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/human_impact_2_0_0.json b/data/json/decision_points/human_impact_2_0_0.json new file mode 100644 index 00000000..b2e5ab7a --- /dev/null +++ b/data/json/decision_points/human_impact_2_0_0.json @@ -0,0 +1,29 @@ +{ + "namespace": "ssvc", + "version": "2.0.0", + "key": "HI", + "name": "Human Impact", + "description": "Human Impact is a combination of Safety and Mission impacts.", + "values": [ + { + "key": "L", + "name": "Low", + "description": "Safety Impact:(None OR Minor) AND Mission Impact:(None OR Degraded OR Crippled)" + }, + { + "key": "M", + "name": "Medium", + "description": "(Safety Impact:(None OR Minor) AND Mission Impact:MEF Failure) OR (Safety Impact:Major AND Mission Impact:(None OR Degraded OR Crippled))" + }, + { + "key": "H", + "name": "High", + "description": "(Safety Impact:Hazardous AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Major AND Mission Impact:MEF Failure)" + }, + { + "key": "VH", + "name": "Very High", + "description": "Safety Impact:Catastrophic OR Mission Impact:Mission Failure" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/human_impact_2_0_1.json b/data/json/decision_points/human_impact_2_0_1.json new file mode 100644 index 00000000..6c83e47e --- /dev/null +++ b/data/json/decision_points/human_impact_2_0_1.json @@ -0,0 +1,29 @@ +{ + "namespace": "ssvc", + "version": "2.0.1", + "key": "HI", + "name": "Human Impact", + "description": "Human Impact is a combination of Safety and Mission impacts.", + "values": [ + { + "key": "L", + "name": "Low", + "description": "Safety Impact:(Negligible) AND Mission Impact:(None OR Degraded OR Crippled)" + }, + { + "key": "M", + "name": "Medium", + "description": "(Safety Impact:Negligible AND Mission Impact:MEF Failure) OR (Safety Impact:Marginal AND Mission Impact:(None OR Degraded OR Crippled))" + }, + { + "key": "H", + "name": "High", + "description": "(Safety Impact:Critical AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Marginal AND Mission Impact:MEF Failure)" + }, + { + "key": "VH", + "name": "Very High", + "description": "Safety Impact:Catastrophic OR Mission Impact:Mission Failure" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/mission_and_well-being_impact_1_0_0.json b/data/json/decision_points/mission_and_well-being_impact_1_0_0.json new file mode 100644 index 00000000..9751bded --- /dev/null +++ b/data/json/decision_points/mission_and_well-being_impact_1_0_0.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "MWI", + "name": "Mission and Well-Being Impact", + "description": "Mission and Well-Being Impact is a combination of Mission Prevalence and Public Well-Being Impact.", + "values": [ + { + "key": "L", + "name": "Low", + "description": "Mission Prevalence:Minimal AND Public Well-Being Impact:Minimal" + }, + { + "key": "M", + "name": "Medium", + "description": "Mission Prevalence:Support AND Public Well-Being Impact:(Minimal OR Material)" + }, + { + "key": "H", + "name": "High", + "description": "Mission Prevalence:Essential OR Public Well-Being Impact:(Irreversible)" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/mission_impact_1_0_0.json b/data/json/decision_points/mission_impact_1_0_0.json new file mode 100644 index 00000000..456db1bd --- /dev/null +++ b/data/json/decision_points/mission_impact_1_0_0.json @@ -0,0 +1,34 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "MI", + "name": "Mission Impact", + "description": "Impact on Mission Essential Functions of the Organization", + "values": [ + { + "key": "N", + "name": "None", + "description": "Little to no impact" + }, + { + "key": "NED", + "name": "Non-Essential Degraded", + "description": "Degradation of non-essential functions; chronic degradation would eventually harm essential functions" + }, + { + "key": "MSC", + "name": "MEF Support Crippled", + "description": "Activities that directly support essential functions are crippled; essential functions continue for a time" + }, + { + "key": "MEF", + "name": "MEF Failure", + "description": "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" + }, + { + "key": "MF", + "name": "Mission Failure", + "description": "Multiple or all mission essential functions fail; ability to recover those functions degraded; organization\u2019s ability to deliver its overall mission fails" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/mission_impact_2_0_0.json b/data/json/decision_points/mission_impact_2_0_0.json new file mode 100644 index 00000000..9d096ce0 --- /dev/null +++ b/data/json/decision_points/mission_impact_2_0_0.json @@ -0,0 +1,29 @@ +{ + "namespace": "ssvc", + "version": "2.0.0", + "key": "MI", + "name": "Mission Impact", + "description": "Impact on Mission Essential Functions of the Organization", + "values": [ + { + "key": "D", + "name": "Degraded", + "description": "Little to no impact up to degradation of non-essential functions; chronic degradation would eventually harm essential functions" + }, + { + "key": "MSC", + "name": "MEF Support Crippled", + "description": "Activities that directly support essential functions are crippled; essential functions continue for a time" + }, + { + "key": "MEF", + "name": "MEF Failure", + "description": "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" + }, + { + "key": "MF", + "name": "Mission Failure", + "description": "Multiple or all mission essential functions fail; ability to recover those functions degraded; organization\u2019s ability to deliver its overall mission fails" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/public_safety_impact_1_0_0.json b/data/json/decision_points/public_safety_impact_1_0_0.json new file mode 100644 index 00000000..bc8ec442 --- /dev/null +++ b/data/json/decision_points/public_safety_impact_1_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "PSI", + "name": "Public Safety Impact", + "description": "A coarse-grained representation of impact to public safety.", + "values": [ + { + "key": "M", + "name": "Minimal", + "description": "Safety Impact:(None OR Minor)" + }, + { + "key": "S", + "name": "Significant", + "description": "Safety Impact:(Major OR Hazardous OR Catastrophic)" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/public_safety_impact_2_0_0.json b/data/json/decision_points/public_safety_impact_2_0_0.json new file mode 100644 index 00000000..81f414d8 --- /dev/null +++ b/data/json/decision_points/public_safety_impact_2_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "2.0.0", + "key": "PSI", + "name": "Public Safety Impact", + "description": "A coarse-grained representation of impact to public safety.", + "values": [ + { + "key": "M", + "name": "Minimal", + "description": "Safety Impact:(None OR Minor)" + }, + { + "key": "S", + "name": "Significant", + "description": "Safety Impact:(Major OR Hazardous OR Catastrophic)" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/public_safety_impact_2_0_1.json b/data/json/decision_points/public_safety_impact_2_0_1.json new file mode 100644 index 00000000..b993b033 --- /dev/null +++ b/data/json/decision_points/public_safety_impact_2_0_1.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "2.0.1", + "key": "PSI", + "name": "Public Safety Impact", + "description": "A coarse-grained representation of impact to public safety.", + "values": [ + { + "key": "M", + "name": "Minimal", + "description": "Safety Impact:Negligible" + }, + { + "key": "S", + "name": "Significant", + "description": "Safety Impact:(Marginal OR Critical OR Catastrophic)" + } + ] +} \ No newline at end of file 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 new file mode 100644 index 00000000..566b80c4 --- /dev/null +++ b/data/json/decision_points/public_value_added_1_0_0.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "PVA", + "name": "Public Value Added", + "description": "How much value would a publication from the coordinator benefit the broader community?", + "values": [ + { + "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", + "name": "Ampliative", + "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": "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/data/json/decision_points/public_well-being_impact_1_0_0.json b/data/json/decision_points/public_well-being_impact_1_0_0.json new file mode 100644 index 00000000..7e6556f4 --- /dev/null +++ b/data/json/decision_points/public_well-being_impact_1_0_0.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "PWI", + "name": "Public Well-Being Impact", + "description": "A coarse-grained representation of impact to public well-being.", + "values": [ + { + "key": "M", + "name": "Minimal", + "description": "The effect is below the threshold for all aspects described in material. " + }, + { + "key": "M", + "name": "Material", + "description": "Any one or more of these conditions hold. Physical harm: Does one or more of the following: (a) Causes physical distress or injury to system users. (b) Introduces occupational safety hazards. (c) Reduces and/or results in failure of cyber-physical system safety margins. Environment: Major externalities (property damage, environmental damage, etc.) are imposed on other parties. Financial: Financial losses likely lead to bankruptcy of multiple persons. Psychological: Widespread emotional or psychological harm, sufficient to necessitate counseling or therapy, impact populations of people. " + }, + { + "key": "I", + "name": "Irreversible", + "description": "Any one or more of these conditions hold. Physical harm: One or both of the following are true: (a) Multiple fatalities are likely.(b) The cyber-physical system, of which the vulnerable componen is a part, is likely lost or destroyed. Environment: Extreme or serious externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) are imposed on other parties. Financial: Social systems (elections, financial grid, etc.) supported by the software are destabilized and potentially collapse. Psychological: N/A " + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/report_credibility_1_0_0.json b/data/json/decision_points/report_credibility_1_0_0.json new file mode 100644 index 00000000..0b1c910a --- /dev/null +++ b/data/json/decision_points/report_credibility_1_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "RC", + "name": "Report Credibility", + "description": "Is the report credible?", + "values": [ + { + "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 new file mode 100644 index 00000000..195b8c33 --- /dev/null +++ b/data/json/decision_points/report_public_1_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "RP", + "name": "Report Public", + "description": "Is a viable report of the details of the vulnerability already publicly available?", + "values": [ + { + "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/data/json/decision_points/safety_impact_1_0_0.json b/data/json/decision_points/safety_impact_1_0_0.json new file mode 100644 index 00000000..f76474e1 --- /dev/null +++ b/data/json/decision_points/safety_impact_1_0_0.json @@ -0,0 +1,34 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "SI", + "name": "Safety Impact", + "description": "The safety impact of the vulnerability.", + "values": [ + { + "key": "N", + "name": "None", + "description": "The effect is below the threshold for all aspects described in Minor." + }, + { + "key": "M", + "name": "Minor", + "description": "Any one or more of these conditions hold. Physical harm: Physical discomfort for users (not operators) of the system. 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": "J", + "name": "Major", + "description": "Any one or more of these conditions hold. Physical harm: Physical distress and injuries for users (not operators) of the system. 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": "H", + "name": "Hazardous", + "description": "Any one or more of these conditions hold. Physical harm: Serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures. 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 immediate fatalities (Emergency response probably cannot save the victims.) 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/data/json/decision_points/safety_impact_2_0_0.json b/data/json/decision_points/safety_impact_2_0_0.json new file mode 100644 index 00000000..795813bb --- /dev/null +++ b/data/json/decision_points/safety_impact_2_0_0.json @@ -0,0 +1,29 @@ +{ + "namespace": "ssvc", + "version": "2.0.0", + "key": "SI", + "name": "Safety Impact", + "description": "The safety impact of the vulnerability. (based on IEC 61508)", + "values": [ + { + "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." + }, + { + "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." + }, + { + "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." + }, + { + "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." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/supplier_cardinality_1_0_0.json b/data/json/decision_points/supplier_cardinality_1_0_0.json new file mode 100644 index 00000000..36088dcc --- /dev/null +++ b/data/json/decision_points/supplier_cardinality_1_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "SC", + "name": "Supplier Cardinality", + "description": "How many suppliers are responsible for the vulnerable component and its remediation or mitigation plan?", + "values": [ + { + "key": "O", + "name": "One", + "description": "There is only one supplier of the vulnerable component." + }, + { + "key": "M", + "name": "Multiple", + "description": "There are multiple suppliers of the vulnerable component." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/supplier_contacted_1_0_0.json b/data/json/decision_points/supplier_contacted_1_0_0.json new file mode 100644 index 00000000..526ef3e0 --- /dev/null +++ b/data/json/decision_points/supplier_contacted_1_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "SC", + "name": "Supplier Contacted", + "description": "Has the reporter made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method?", + "values": [ + { + "key": "N", + "name": "No", + "description": "The supplier has not been contacted." + }, + { + "key": "Y", + "name": "Yes", + "description": "The supplier has been contacted." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/supplier_engagement_1_0_0.json b/data/json/decision_points/supplier_engagement_1_0_0.json new file mode 100644 index 00000000..cce9d92a --- /dev/null +++ b/data/json/decision_points/supplier_engagement_1_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "SE", + "name": "Supplier Engagement", + "description": "Is the supplier responding to the reporter\u2019s contact effort and actively participating in the coordination effort?", + "values": [ + { + "key": "A", + "name": "Active", + "description": "The supplier is responding to the reporter\u2019s contact effort and actively participating in the coordination effort." + }, + { + "key": "U", + "name": "Unresponsive", + "description": "The supplier is not responding to the reporter\u2019s contact effort and not actively participating in the coordination effort." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/supplier_involvement_1_0_0.json b/data/json/decision_points/supplier_involvement_1_0_0.json new file mode 100644 index 00000000..0adcf48d --- /dev/null +++ b/data/json/decision_points/supplier_involvement_1_0_0.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "SI", + "name": "Supplier Involvement", + "description": "What is the state of the supplier\u2019s work on addressing the vulnerability?", + "values": [ + { + "key": "FR", + "name": "Fix Ready", + "description": "The supplier has provided a patch or fix." + }, + { + "key": "C", + "name": "Cooperative", + "description": "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." + }, + { + "key": "UU", + "name": "Uncooperative/Unresponsive", + "description": "The supplier has not responded, declined to generate a remediation, or no longer exists." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/system_exposure_1_0_0.json b/data/json/decision_points/system_exposure_1_0_0.json new file mode 100644 index 00000000..60b5dc75 --- /dev/null +++ b/data/json/decision_points/system_exposure_1_0_0.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "EXP", + "name": "System Exposure", + "description": "The Accessible Attack Surface of the Affected System or Service", + "values": [ + { + "key": "S", + "name": "Small", + "description": "Local service or program; highly controlled network" + }, + { + "key": "C", + "name": "Controlled", + "description": "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\u2019s 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." + }, + { + "key": "U", + "name": "Unavoidable", + "description": "Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers)" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/system_exposure_1_0_1.json b/data/json/decision_points/system_exposure_1_0_1.json new file mode 100644 index 00000000..f287944d --- /dev/null +++ b/data/json/decision_points/system_exposure_1_0_1.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.0.1", + "key": "EXP", + "name": "System Exposure", + "description": "The Accessible Attack Surface of the Affected System or Service", + "values": [ + { + "key": "S", + "name": "Small", + "description": "Local service or program; highly controlled network" + }, + { + "key": "C", + "name": "Controlled", + "description": "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\u2019s 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." + }, + { + "key": "O", + "name": "Open", + "description": "Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers)" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/technical_impact_1_0_0.json b/data/json/decision_points/technical_impact_1_0_0.json new file mode 100644 index 00000000..a844a82b --- /dev/null +++ b/data/json/decision_points/technical_impact_1_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "TI", + "name": "Technical Impact", + "description": "The technical impact of the vulnerability.", + "values": [ + { + "key": "P", + "name": "Partial", + "description": "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." + }, + { + "key": "T", + "name": "Total", + "description": "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." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/utility_1_0_0.json b/data/json/decision_points/utility_1_0_0.json new file mode 100644 index 00000000..c71273ce --- /dev/null +++ b/data/json/decision_points/utility_1_0_0.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "U", + "name": "Utility", + "description": "The Usefulness of the Exploit to the Adversary", + "values": [ + { + "key": "L", + "name": "Laborious", + "description": "Virulence:Slow and Value Density:Diffuse" + }, + { + "key": "E", + "name": "Efficient", + "description": "Virulence:Rapid and Value Density:Diffuse OR Virulence:Slow and Value Density:Concentrated" + }, + { + "key": "S", + "name": "Super Effective", + "description": "Virulence:Rapid and Value Density:Concentrated" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/utility_1_0_1.json b/data/json/decision_points/utility_1_0_1.json new file mode 100644 index 00000000..a1b72bce --- /dev/null +++ b/data/json/decision_points/utility_1_0_1.json @@ -0,0 +1,24 @@ +{ + "namespace": "ssvc", + "version": "1.0.1", + "key": "U", + "name": "Utility", + "description": "The Usefulness of the Exploit to the Adversary", + "values": [ + { + "key": "L", + "name": "Laborious", + "description": "Automatable:No AND Value Density:Diffuse" + }, + { + "key": "E", + "name": "Efficient", + "description": "(Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)" + }, + { + "key": "S", + "name": "Super Effective", + "description": "Automatable:Yes AND Value Density:Concentrated" + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/value_density_1_0_0.json b/data/json/decision_points/value_density_1_0_0.json new file mode 100644 index 00000000..2c2db1a4 --- /dev/null +++ b/data/json/decision_points/value_density_1_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "VD", + "name": "Value Density", + "description": "The concentration of value in the target", + "values": [ + { + "key": "D", + "name": "Diffuse", + "description": "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." + }, + { + "key": "C", + "name": "Concentrated", + "description": "The system that contains the vulnerable component is rich in resources. Heuristically, such systems are often the direct responsibility of \u201csystem operators\u201d rather than users." + } + ] +} \ No newline at end of file diff --git a/data/json/decision_points/virulence_1_0_0.json b/data/json/decision_points/virulence_1_0_0.json new file mode 100644 index 00000000..dfa91097 --- /dev/null +++ b/data/json/decision_points/virulence_1_0_0.json @@ -0,0 +1,19 @@ +{ + "namespace": "ssvc", + "version": "1.0.0", + "key": "V", + "name": "Virulence", + "description": "The speed at which the vulnerability can be exploited.", + "values": [ + { + "key": "S", + "name": "Slow", + "description": "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." + }, + { + "key": "R", + "name": "Rapid", + "description": "Steps 1-4 of the of the kill chain can be reliably automated. If the vulnerability allows remote code execution or command injection, the default response should be rapid." + } + ] +} \ No newline at end of file diff --git a/data/schema/Decision_Point.schema.json b/data/schema/Decision_Point.schema.json new file mode 100644 index 00000000..f4ddb450 --- /dev/null +++ b/data/schema/Decision_Point.schema.json @@ -0,0 +1,60 @@ +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "title": "Decision Point schema definition", + "$id": "https://github.com/CERTCC/SSVC/tree/main/data/schema/Decision_Point.schema.json", + "description": "Decision points are the basic building blocks of SSVC decision functions. Individual decision points describe a single aspect of the input to a decision function.", + "type": "object", + "additionalProperties": false, + "properties": { + "namespace": { + "type": "string", + "description": "Namespace (a short, unique string): For example, \"ssvc\" or \"cvss\" to indicate the source of the decision point" + }, + "version": { + "type": "string", + "description": "Version (a semantic version string) that identifies this object" + }, + "key": { + "type": "string", + "description": "A key (a short, unique string) that can be used to identify the Decision Point/Decision Point value in a shorthand way" + }, + "name": { + "type": "string", + "description": "A short label that captures the description of the Decision Point or the Group of Decision Points." + }, + "description": { + "type": "string", + "description": "Description of the Decision Point or the Group of Decision Points." + }, + "values": { + "description": "Decision Point Values are valid results from a Decision Point", + "uniqueItems": true, + "type": "array", + "items": { + "type": "object", + "properties": { + "key": { + "type": "string", + "description": "A key (a short, unique string) that can be used to identify the Decision Point/Decision Point value in a shorthand way" + }, + "name": { + "type": "string", + "description": "A short label that captures the description of the Decision Point or the Group of Decision Points." + }, + "description": { + "type": "string", + "description": "Description of the Decision Point or the Group of Decision Points." + } + } + } + } + }, + "required": [ + "namespace", + "version", + "key", + "name", + "description", + "values" + ] +} diff --git a/data/schema/Decision_Point_Group.schema.json b/data/schema/Decision_Point_Group.schema.json new file mode 100644 index 00000000..dd7cb4a0 --- /dev/null +++ b/data/schema/Decision_Point_Group.schema.json @@ -0,0 +1,79 @@ +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "title": "Decision Points Group schema definition", + "$id": "https://github.com/CERTCC/SSVC/tree/main/data/schema/Decision_Point_Group.schema.json", + "type": "object", + "additionalProperties": false, + "properties": { + "version": { + "type": "string", + "description": "Version (a semantic version string) that identifies this object" + }, + "name": { + "type": "string", + "description": "A short label that captures the description of the Decision Point or the Group of Decision Points." + }, + "description": { + "type": "string", + "description": "Description of the Decision Point or the Group of Decision Points." + }, + "decision_points": { + "description": "Decision points are the basic building blocks of SSVC decision functions. Individual decision points describe a single aspect of the input to a decision function.", + "additionalProperties": false, + "type": "array", + "items": { + "type": "object", + "properties": { + "namespace": { + "type": "string", + "description": "Namespace (a short, unique string): For example, \"ssvc\" or \"cvss\" to indicate the source of the decision point" + }, + "version": { + "type": "string", + "description": "Version (a semantic version string) that identifies this object" + }, + "key": { + "type": "string", + "description": "A key (a short, unique string) that can be used to identify the Decision Point/Decision Point value in a shorthand way" + }, + "name": { + "type": "string", + "description": "A short label that captures the description of the Decision Point or the Group of Decision Points." + }, + "description": { + "type": "string", + "description": "Description of the Decision Point or the Group of Decision Points." + }, + "values": { + "description": "Decision Point Values are valid results from a Decision Point", + "uniqueItems": true, + "type": "array", + "items": { + "type": "object", + "properties": { + "key": { + "type": "string", + "description": "A key (a short, unique string) that can be used to identify the Decision Point/Decision Point value in a shorthand way" + }, + "name": { + "type": "string", + "description": "A short label that captures the description of the Decision Point or the Group of Decision Points." + }, + "description": { + "type": "string", + "description": "Description of the Decision Point or the Group of Decision Points." + } + } + } + } + } + } + } + }, + "required": [ + "version", + "name", + "description", + "decision_points" + ] +} diff --git a/doc/README.md b/doc/README.md deleted file mode 100644 index 6754c96b..00000000 --- a/doc/README.md +++ /dev/null @@ -1,204 +0,0 @@ -# Definitional documents - -This folder contains the text documents that describe the decision process, the decision points, the possible decision -values, and the decision trees that should be used to reach prioritization decisions. - -The current draft should be compiled into `/draft/ssvc.html` for easy viewing, though it may be behind the markdown source -by a couple commits. - -The documents are in markdown for easy editing. -All the source files needed to create a polished document are in the [`md_src_files`](md_src_files) folder. -The work on version 1 started with the version of the paper published -at [WEIS 2020](https://weis2020.econinfosec.org/wp-content/uploads/sites/8/2020/06/weis20-final6.pdf). -A copy of this document and other prior drafts is in the `/pdfs` folder. - -## Markdown file naming conventions - -The `*.md` files should be limited to one file per chapter or section, for easier editing and merging. -The current numbering scheme is important so the command line `*` ingests the files in the right (i.e., ASCII-sort) order. -File names follow the convention `CC_SS_name.md` where: - -- `CC` is a zero-padded two-digit chapter number -- `SS` (optional) is a zero-padded two-digit section number -- `name` is a string derived from the first heading in the file - -So for example, a file whose content starts with `## Foo` representing the third section of chapter two would likely be named `02_03_foo.md`. - -## Makefile - -The [`Makefile`](Makefile) contains pandoc commands line for creating a single HTML and PDF document from the markdown. It also -contains the document metadata (title, authors, date) as command-line arguments. You can: - -```bash -$ make all -``` -to produce both HTML and PDF output, or do either of -```bash -$ make pdf -$ make html -``` -for the respective output. -Output of the `make` commands can be found in `/draft`. - -Note that the `Makefile` was used as the basis for the github action -[`.github/workflows/pandoc_html_pdf.yaml`](./github/workflows/pandoc_html_pdf.yaml), which should be maintained in sync -with the `Makefile` in the future. - - -The `*how-to` files contain discussion on document composition and style. Please align any commits with the existing -how-to guidance. At present (Aug 2020), the how-to guidance is not yet fixed, but it should only change with community -discussion. - - - -# Style Guide and How-To - -In the text, please use the following conventions: -- Names of decision points are capitalized and italics (md is `*` or `_`) -- Values for specific decisions at a decision point are lower case and bold (md is `**` or `__`) - - Values uppercase at the start of a sentence, but try to avoid such sentence constructions. -- Headings that declare the decision point name or values should not be additionally emphasized. - - That is, if the name is the whole heading, don't use emphasis. - - If the name is part of another heading, use emphasis. -- Decision points, decision values, and stakeholder decisions should always be in a link cross-referenced to the table in which they are defined. - -So we would have: -`[_Utility_](#utility)` or `[*Technical Impact*](#technical-impact)` which might have values of `[super effective](#utility)` or `[partial](#technical-impact)` - -- Names of decisions are italicized (`*` or `_`) and lower case. - -For example: the decision is to move forward with `[*scheduled*](#applier-decisions)` priority. - - - [ ] This choice collides with decision point names. However, the cap vs lowercase combined with the anchor crossreference is probably enough for readers to distinguish them. Seek feedback on this. - - -- Short summaries after the section header declaring the name of the decision point should be in block quotes. - - For example: -``` -### Exploitation -> Evidence of Active Exploitation of a Vulnerability -``` - - - The short summary should be in title case. - - There should not be a blank line between the heading and the block quote - - -## How To Use Cross References - -- Cross references to other sections can be accomplished with the `[text](link)` syntax for links. - - The text to appear goes in `[]` - - The heading to link to goes in `()` -- Use full heading text, lowercased, with `-` instead of spaces. - - for example [Section 2](#current-state-of-practice) - - See: https://gist.github.com/asabaylus/3071099 - -### To create an arbitrary anchor -- use HTML, e.g.: -```html - -``` -- see also https://stackoverflow.com/questions/5319754/cross-reference-named-anchor-in-markdown - - -## Terms quoted from other sources - -- In order not to collide use of emphasis, italics (`*word*`) should not be used to identify a vocabulary word that is not the name of a decision point. - - If the word or phrase need not be emphasized, it should simply but put in double quotes (`"`). - - If the word or phrase needs to be emphasized because it is critical to understanding the passage and it should stand out from the surrounding text, bold can be used (`**` or `__`). - - This style should be used sparingly, primarily for the first place that a key term is defined. - -- Comments in the source code use HTML comments: -``` - -``` - -- Obviously don't put sensitive information in the comments. -- Comments should be used to note where editorial decisions have been made to about style. -- For example, though `*Exposure*` is the decision point, we may still want to talk about exposure generally, and it might be helpful to note in a comment that the word exposure is not emphasized on purpose. - -## Do not use footnotes. - -- There is a markdown style for footnotes (https://pandoc.org/MANUAL.html#footnote) - - But right now GFM doesn't support that. - - Footnotes and asides that were not references in v1 have been written in to the flow of the text. - -- If there is some lengthy aside that is helpful, but is too long to be written into the flow of the text, it should be set off with a `----` (horizontal rule) and marked as an aside and ended with another hrule. -- This style can only be used for asides that are at least a full paragraph. -- To mark it as an aside, give it a title in block quote format - -``` ----- -> aside title - -aside content ----- -``` - -- Don't use Headings (`#`, `##`, etc.) because this will interfere with section numbering. -- It would be good practice to provide an HTML anchor with the same name as the aside title, so we can cross reference the box elsewhere. - - -## JSON - -- When describing JSON literals in the `.md` documents, they should be marked up as `code literals` using backticks (`). - - -## Tables - -- GFM uses the `pipe_tables` markdown extension by default, so tables should use that format. -- Tables should avoid HTML or LaTeX literal tables, as those aren't portable. - - If absolutely necessary, include both. -- Note that when pandoc renders a pipe table into LaTeX if " the cell contents will wrap, with the relative cell widths determined by the number of dashes in the line separating the table header from the table body. - - (For example `---|-` would make the first column 3/4 and the second column 1/4 of the full text width.) " https://pandoc.org/MANUAL.html#tables - -- Use the `table_captions` extension - - In GFM this will render as text, but it will still be helpful. - - "A caption may optionally be provided with all 4 kinds of tables (as illustrated in the examples below). - - A caption is a paragraph beginning with the string `Table:` (or just `:`), which will be stripped off. It may appear either before or after the table." - - Put `Table:` marker above the table, not below it. - - -## Embedding images - -Use the supported markdown for images where possible and support the link_attributes extension. -https://pandoc.org/MANUAL.html#images - -`![Caption](foo.jpg){width=90%}` - -This will render as a figure in latex as long as it is on a line all by itself and the implicit_figures extension to pandoc is used. -It will render as a normal image in GFM. - -## Spacing - -- Pandoc Markdown will treat a period (`.`) followed by two spaces (` `) at the end of a line as a request for a line break. -- Always use only one space after a period, especially at the end of a line. - -- Use unicode characters for opening and closing double quote marks (`“` and `”`) rather than a straight dumb quote mark (`"`). -- Do not try to use LaTeX conventions of (``) and (''). - -## Notes on References - -- Would most prefer using `pandoc-citeproc`. -- GFM does not natively support bibtex citations. However, the pandoc markdown syntax is to use `@referencetag`. -- Documentation for citation processing: - - https://pandoc.org/MANUAL.html#citations -- The @ citation syntax shouldn't interfere with @ mentions. GFM only allows @ mentions in issues and pull request. - - https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown - -### The preferred citation method is as follows: - -1. Search [`md_src_files/sources_ssvc.bib`](md_src_files/sources_ssvc.bib) for the desired reference -2. If it's there, use `[@referencetag]` in the markdown text. For example, the tag in the entry beginning with -```bibtex - @book{simon1996sciences, -``` -is `simon1996sciences` -3. If it's not there, add it to the correct subpart of the bibtex file. (books are together, articles are together, CVSS publications are together, etc.) Use authorYYYYword style for the tags (this is the default Google Scholar naming style, which is a good place to get decently formatted bibtex that you can tidy up). Then use the [@referencetag] in the markdown text. - - -Though the `[@tag]` command won't reference on github, the `html` target in the `Makefile` has the right pandoc commands to create a pretty HTML file with a proper references section. - - - - - diff --git a/doc/md_src_files/01_introduction.md b/doc/md_src_files/01_introduction.md deleted file mode 100644 index c1e6d9bd..00000000 --- a/doc/md_src_files/01_introduction.md +++ /dev/null @@ -1,38 +0,0 @@ - - -# 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](#version-2-changelog). - -The document is organized as follows. -- [Current State of Practice](#current-state-of-practice) summarizes the current state of vulnerability management. -- [Representing Information for Decisions About Vulnerabilities](#representing-information-for-decisions-about-vulnerabilities) describes our design goals for an improved prioritization method. -- [Vulnerability Management Decisions](#vulnerability-management-decisions) defines who the decision makers are and what options they are deciding among. -- [Likely Decision Points and Relevant Data](#likely-decision-points-and-relevant-data) proposes a definition of decision points that a stakeholder might use during vulnerability management. -- [Prioritization](#prioritization) combines these decision points into example decision trees that can be used to prioritize action on a work item. -- [Evaluation of the Draft Trees](#evaluation-of-the-draft-trees) describes an early test of this method against the design goals, as much to show an adequate usability test methodology as for the results. -- [Worked example](#worked-example) provides examples of applying the methodology to sample vulnerabilities and discusses the relationship between SSVC and other vulnerability management prioritization systems. -- [Future Work](#future-work) identifies ideas we haven't had time to incorporate yet. -- [Limitations](#limitations) identifies limitations in the design. -- [Conclusion](#conclusion) provides some final thoughts. 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_05_utility.md b/doc/md_src_files/05_05_utility.md deleted file mode 100644 index 2603c895..00000000 --- a/doc/md_src_files/05_05_utility.md +++ /dev/null @@ -1,47 +0,0 @@ -## Utility -> The Usefulness of the Exploit to the Adversary - -[*Utility*](#utility) estimates an adversary's benefit compared to their effort based on the assumption that they can exploit the vulnerability. -[*Utility*](#utility) is independent from the state of [*Exploitation*](#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*](#exploitation) measures whether the **capital cost** of producing reliable exploit code has been paid or not. -[*Utility*](#utility) estimates the **marginal cost** of each exploitation event. -More plainly, [*Utility*](#utility) is about how much an adversary might benefit from a campaign using the vulnerability in question, whereas [*Exploitation*](#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*](#automatable) as ([*no*](#automatable) or [*yes*](#automatable)) and [*Value Density*](#value-density) as ([*diffuse*](#value-density) or [*concentrated*](#value-density)) define those decision points. - -Roughly, [*Utility*](#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*](#utility) as laborious, efficient, or super effective, as described in [Utility Decision Values](#table-utility). [The next table](#table-utility-2) is an equivalent expression of [*Utility*](#utility) that resembles a lookup table in a program. - -Table: Utility Decision Values - -| Value | Definition | -| :--- | :---------- | -| Laborious | *No* to automatable and diffuse value | -| Efficient | {*Yes* to automatable and diffuse value} OR {*No* to automatable and concentrated value} | -| Super Effective | *Yes* to automatable and concentrated value | - -Table: Utility to the Adversary, as a Combination of Automatable and Value Density - -| *Automatable* | *Value Density* | *Utility* | -| ----------- | --------------- | --: | -| *no* | *diffuse* | laborious | -| *no* | *concentrated* | efficient | -| *yes* | *diffuse* | efficient | -| *yes* | *concentrated* | super 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](https://zerodium.com/program.html), make such pricing structures public. -The valuable exploits track the [*Automatable*](#automatable) and [*Value Density*](#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*](#automatable) exploits for different systems are priced relative to each other is more idiosyncratic. -Price does not only track the [*Value Density*](#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*](#utility) decision point and the exploit markets. 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/05_09_system_exposure.md b/doc/md_src_files/05_09_system_exposure.md deleted file mode 100644 index e0190db4..00000000 --- a/doc/md_src_files/05_09_system_exposure.md +++ /dev/null @@ -1,43 +0,0 @@ -## 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. - -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 - -[*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*](#system-exposure) can be readily informed by network scanning techniques. -For example, if the vulnerable component is visible on [Shodan](www.shodan.io) or by some other external scanning service, then it is [*open*](#system-exposure). -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.). - -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. -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). - -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). - -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/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_00_prioritization.md b/doc/md_src_files/07_00_prioritization.md deleted file mode 100644 index 64d04299..00000000 --- a/doc/md_src_files/07_00_prioritization.md +++ /dev/null @@ -1,19 +0,0 @@ -# Prioritization - -Given a specific stakeholder decision and set of useful decision points, we are now in a position to combine them into a comprehensive set of decisions about the priority with which to act. -The definition of choices can take a logical form, such as: - - IF - - ([*Exploitation*](#exploitation) IS [PoC](#exploitation)) AND - - ([*Exposure*](#exposure) IS [controlled](#exploitation)) AND - - ([*Automatable*](#automatable) IS [no](#automatable)) AND - - ([*Human Impact*](#human-impact) IS [medium](#human-impact)) - - THEN priority is *scheduled*. - -This example logical statement is captured in (line 35 of the deployer `.csv` file)[https://github.com/CERTCC/SSVC/blob/main/data/csvs/deployer-options.csv#L35]. - -There are different formats for capturing these prioritization decisions depending on how and where they are going to be used. -In this paper, we primarily represent a full set of guidance on how one stakeholder will make a decision as a **decision tree**. -This section presents example trees for each stakeholder: supplier, deployer, and coordinator. -This section also provides some guidance on how to [construct and customize a decision tree](#tree-construction-and-customization-guidance) and [gather evidence](#evidence-gathering-guidance) to make decisions. -How this decision information might be stored or communicated is the topic of subsections on [Asset Management](#relationship-to-asset-management) and [Communication](#guidance-on-communicating-results). - diff --git a/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/07_06_asset_management.md b/doc/md_src_files/07_06_asset_management.md deleted file mode 100644 index 467dfd79..00000000 --- a/doc/md_src_files/07_06_asset_management.md +++ /dev/null @@ -1,27 +0,0 @@ -## 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*](#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. -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]. -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. - diff --git a/doc/md_src_files/07_07_development_methodology.md b/doc/md_src_files/07_07_development_methodology.md deleted file mode 100644 index b0437919..00000000 --- a/doc/md_src_files/07_07_development_methodology.md +++ /dev/null @@ -1,9 +0,0 @@ -## 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. - diff --git a/doc/md_src_files/08_communicating_results.md b/doc/md_src_files/08_communicating_results.md deleted file mode 100644 index 255a64c8..00000000 --- a/doc/md_src_files/08_communicating_results.md +++ /dev/null @@ -1,147 +0,0 @@ -# Guidance on Communicating Results - -There are many aspects of SSVC that two parties might want to communicate. -Not every stakeholder will use the decision points to make comparable decisions. -Suppliers and deployers make interdependent decisions, but the actions of one group are not strictly dependent on the other. -Recall that one reason for this is that SSVC is about prioritizing a vulnerability response action in general, not specifically applying a patch that a supplier produced. -Coordinators are particularly interested in facilitating communication because that is their core function. -This section handles three aspects of this challenge: formats for communicating SSVC, how to handle partial or incomplete information, and how to handle information that may change over time. - -This section is about communicating SSVC information about a specific vulnerability. -Any stakeholder making a decision on allocating effort should have a decision tree with its decision points and possible values specified already. -[Representation choices](#representation-choices) and [Tree Construction and Customization Guidance](#tree-construction-and-customization-guidance) discussed how SSVC uses a text file as the canonical form of a decision tree; the example trees can be found in [SSVC/data](https://github.com/CERTCC/SSVC/tree/main/data). -This section discusses the situation where one stakeholder, usually a supplier or coordinator, wants to communicate some information about a specific vulnerability to other stakeholders or constituents. - -## Communication Formats - -We recommend 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](#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*](#technical-impact) becomes `T` and [*Public Safety Impact*](#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](#mission-impact) becomes `Ms` and [efficient](#utility) 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](#public-safety-impact) [*Public Safety Impact*](#public-safety-impact), [total](#technical-impact) [*Technical Impact*](#technical-impact), and [efficient](#utility) [*Utility*](#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](https://github.com/CERTCC/SSVC/blob/main/data/schema/SSVC_Provision.schema.json) is equivalent to a decision tree and documents the full set of logical statements that a stakeholder uses to make decisions. -The [computed schema](https://github.com/CERTCC/SSVC/blob/main/data/schema/SSVC_Computed.schema.json) expresses a set of information about a work item or vulnerability at a point in time. -A computed schema should identify the provision schema used, so the options from which the information was computed are specified. - -Each element of `choices` should be an object that is a key-value pair of `decision point`:`value`, where the term `decision point` is a string derived from the name of the decision point as follows: - - Start with the decision point name as given in [Likely Decision Points and Relevant Data](#likely-decision-points-and-relevant-data). - - Remove any text in parentheses (and the parentheses themselves). - - Remove colon characters, if any (`:`). - - Convert the string to [lower camel case](https://en.wikipedia.org/wiki/Camel_case) by lowercasing the string, capitalizing any letter after a space, and removing all spaces. - -The `value` term is derived the same way as `decision point` except start with the value name as given in the relevant decision point subsection of [Likely Decision Points and Relevant Data](#likely-decision-points-and-relevant-data). - -## Partial or Incomplete Information - -What an analyst knows about a vulnerability may not be complete. -However, the vulnerability management community may still benefit from partial information. -In particular, suppliers and coordinators who might not know everything a deployer knows can still provide benefit to deployers by sharing what partial information they do know. -A second benefit to providing methods for communicating partial information is the reduction of bottlenecks or barriers to information exchange. -A timely partial warning is better than a complete warning that is too late. - -The basic guidance is that the analyst should communicate all of the vulnerability's possible states, to the best of the analyst's knowledge. -If the analyst knows nothing, all states are possible. -For example, [*Utility*](#utility) may be [laborious](#utility), [efficient](#utility), or [super effective](#utility). -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*](#utility) but does not have anything to communicate. -A stakeholder might have information to communicate about some decision points but not others. -If SSVC uses this format to list the values that are in play for a particular vulnerability, there is no need for a special “I don't know” marker. - -The merit in this “list all values” approach emerges when the stakeholder knows that the value for a decision point may be A or B, but not C. -For example, say the analyst knows that [*Value Density*](#value-density) is [diffuse](#value-density) but does not know the value for [*Automatability*](#automatability). -Then the analyst can usefully restrict [*Utility*](#utility) to one of [laborious](#utility) or [efficient](#utility). -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*](#utility), are mostly static. -For [*Utility*](#utility) to change, the market penetration or deployment norms of a vulnerable component would have to meaningfully change. -Some, such as [*State of Exploitation*](#state-of-exploitation), may change quickly but only in one direction. - -Both of these examples are out of the direct control of the vulnerability manager. -Some, such as [*Exposure*](#exposure), change mostly due to actions taken by the organization managing the vulnerable component. -If the actor who can usually trigger a relevant change is the organization using SSVC, then it is relatively straightforward to know when to update the SSVC decision. -That is, the organization should reevaluate the decision when they make a relevant change. -For those decision points that are about topics outside the control of the organization using SSVC, then the organization should occasionally poll their information sources for changes. -The cadence or rate of polls is different for each decision point, based on the expected rate of change. - -We expect that updating information over time will be most useful where the evidence-gathering process can be automated. -Organizations that have mature asset management systems will also find this update process more efficient than those that do not. -For an organization without a mature asset management system, we would recommend putting organizational resources into maturing that function before putting effort into regular updates to vulnerability prioritization decision points. - -The following decision points are usually out of the control of the organization running SSVC. -As an initial heuristic, we suggest the associated polling frequency for each. -These frequencies can be customized, as the update frequency is directly related to the organization's tolerance for the risk that the information is out of date. -As discussed in [Tree Construction and Customization Guidance](#tree-construction-and-customization-guidance), risk tolerance is unique to each organization. -Risk tolerance and risk appetite are primarily reflected in the priority labels (that is, decisions) encoded in the SSVC decision tree, but information polling frequency is also a risk tolerance decision and each organization may choose different time values. - - [*Exploitation*](#exploitation): every 1 day - - [*Technical Impact*](#technical-impact): never (should be static per vulnerability) - - [*Utility*](#utility): every 6 months - - [*Public Safety Impact*](#public-safety-impact): every 1 year - -The following decision points are usually in the control of the organization running SSVC and should be reevaluated when a relevant change is made or during annual reviews of assets. - - - [*Situated Safety Impact*](#situated-safety-impact) - - [*Mission Impact*](#mission-impact) - - [*System Exposure*](#system-exposure) - -If SSVC information is all timestamped appropriately (as discussed earlier in this section), then an analyst can compare the timestamp to the current date and determine whether information is considered stale. -The above rates are heuristic suggestions, and organizations may choose different ones. -Any public repository of vulnerability information should keep a change log of when values change for each decision point, for each vulnerability. -Vulnerability response analysts should keep such change logs as well. -Similar to logging practices recommended for incident response [@nist800-61r2], such practices make the process less error-prone and facilitate after-action reviews. diff --git a/doc/md_src_files/10_evaluation_of_draft_trees.md b/doc/md_src_files/10_evaluation_of_draft_trees.md deleted file mode 100644 index 6d192832..00000000 --- a/doc/md_src_files/10_evaluation_of_draft_trees.md +++ /dev/null @@ -1,166 +0,0 @@ - - -# 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](#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 - -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*](#exploitation), for example, should take the value of [*none*](#exploitation), [*PoC*](#exploitation), or [*active*](#exploitation). -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. - -1. Start at the root node of the relevant decision tree (deployer or supplier). - -2. Document the decision branch that matches the vulnerability for this stakeholder context. - -3. Document the evidence that supports that decision. - -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. | - -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. - -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 | - -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 [@fleiss1973equivalence]. 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 [@householder2020cvd, section 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](#improvements-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 [@allodi2018effect], 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)](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. - -### 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](#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 | - -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. - -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) | - -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*. 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/12_related_systems.md b/doc/md_src_files/12_related_systems.md deleted file mode 100644 index f74d9365..00000000 --- a/doc/md_src_files/12_related_systems.md +++ /dev/null @@ -1,190 +0,0 @@ - -# 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]. -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. - -## 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_v3-1]. -Two examples of this include the U.S. government [see @nist800-115, p. 7-4; @nist800-40r3, p. 4; and @bod15-01] and the global payment card industry [@pcidss_v3] 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 [@wang2017characterizing]. - -CVSS has struggled to adapt to other stakeholder contexts. -Various stakeholder groups have expressed dissatisfaction by making new versions of CVSS, such as medical devices [@mitre2019medical], robotics [@vilches2018towards], and industrial systems [@figueroa2020survey]. -In these three examples, the modifications tend to add complexity to CVSS by adding metrics. -Product vendors have varying degrees of adaptation of CVSS for development prioritization, including but not limited to [Red Hat](https://access.redhat.com/security/updates/classification), [Microsoft](https://www.microsoft.com/en-us/msrc/security-update-severity-rating-system), and [Cisco](https://tools.cisco.com/security/center/resources/security_vulnerability_policy.html#asr). -The vendors codify CVSS’s recommended qualitative severity rankings in different ways, and Red Hat and Microsoft make the user interaction base metric more important. - -> 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. -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. -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*](#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. -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*](#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_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. -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. - -> 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]. - -> 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)](https://www.first.org/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 [@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. - -## 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). - -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). - -## 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. - - -## 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*](#mission-impact) and situated [*Well-being Impact*](#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*](#exploitation), [*System Exposure*](#system-exposure), [*Technical Impact*](#technical-impact), and [*Public Safety Impact*](#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](https://github.com/CERTCC/SSVC/issues) 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*](#exploitation) 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. - - -[*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. - - -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*](#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. -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. -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. - -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). -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). -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. - -[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. - -## 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). -[*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. - -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. -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). -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). -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. -This wouldn't make a determination for an analyst, but would be a step towards automatic assessment of the decision point. diff --git a/doc/md_src_files/15_conclusion.md b/doc/md_src_files/15_conclusion.md deleted file mode 100644 index 824b01d8..00000000 --- a/doc/md_src_files/15_conclusion.md +++ /dev/null @@ -1,12 +0,0 @@ - - - -# 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](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. 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/docs/_generated/decision_points/automatable.md b/docs/_generated/decision_points/automatable.md new file mode 120000 index 00000000..a8229e62 --- /dev/null +++ b/docs/_generated/decision_points/automatable.md @@ -0,0 +1 @@ +automatable_2_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/automatable_2_0_0.md b/docs/_generated/decision_points/automatable_2_0_0.md new file mode 100644 index 00000000..96befcd5 --- /dev/null +++ b/docs/_generated/decision_points/automatable_2_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Automatable v2.0.0" + + === "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 for this vulnerability. These steps are (1) reconnaissance, (2) weaponization, (3) delivery, and (4) exploitation. | + | Yes | Attackers can reliably automate steps 1-4 of the kill chain. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/automatable_2_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/exploitation.md b/docs/_generated/decision_points/exploitation.md new file mode 120000 index 00000000..083c9359 --- /dev/null +++ b/docs/_generated/decision_points/exploitation.md @@ -0,0 +1 @@ +exploitation_1_1_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/exploitation_1_0_0.md b/docs/_generated/decision_points/exploitation_1_0_0.md new file mode 100644 index 00000000..1b07d383 --- /dev/null +++ b/docs/_generated/decision_points/exploitation_1_0_0.md @@ -0,0 +1,18 @@ + +!!! note "Exploitation v1.0.0" + + === "Text" + + The present state of exploitation of the 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 | 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. | + | Active | Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/exploitation_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/exploitation_1_1_0.md b/docs/_generated/decision_points/exploitation_1_1_0.md new file mode 100644 index 00000000..f45a41a5 --- /dev/null +++ b/docs/_generated/decision_points/exploitation_1_1_0.md @@ -0,0 +1,18 @@ + +!!! note "Exploitation v1.1.0" + + === "Text" + + The present state of exploitation of the vulnerability. + + | Value | Definition | + |:-----|:-----------| + | None | There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability. | + | Public PoC | One of the following is true: (1) Typical public PoC exists in sources such as Metasploit or websites like ExploitDB; or (2) the vulnerability has a well-known method of exploitation. | + | Active | Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/exploitation_1_1_0.json" %} + ``` diff --git a/docs/_generated/decision_points/human_impact.md b/docs/_generated/decision_points/human_impact.md new file mode 120000 index 00000000..22faf37a --- /dev/null +++ b/docs/_generated/decision_points/human_impact.md @@ -0,0 +1 @@ +human_impact_2_0_1.md \ No newline at end of file diff --git a/docs/_generated/decision_points/human_impact_2_0_0.md b/docs/_generated/decision_points/human_impact_2_0_0.md new file mode 100644 index 00000000..7331fb39 --- /dev/null +++ b/docs/_generated/decision_points/human_impact_2_0_0.md @@ -0,0 +1,19 @@ + +!!! note "Human Impact v2.0.0" + + === "Text" + + Human Impact is a combination of Safety and Mission impacts. + + | Value | Definition | + |:-----|:-----------| + | Low | Safety Impact:(None OR Minor) AND Mission Impact:(None OR Degraded OR Crippled) | + | Medium | (Safety Impact:(None OR Minor) AND Mission Impact:MEF Failure) OR (Safety Impact:Major AND Mission Impact:(None OR Degraded OR Crippled)) | + | High | (Safety Impact:Hazardous AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Major AND Mission Impact:MEF Failure) | + | Very High | Safety Impact:Catastrophic OR Mission Impact:Mission Failure | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/human_impact_2_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/human_impact_2_0_1.md b/docs/_generated/decision_points/human_impact_2_0_1.md new file mode 100644 index 00000000..d5bf8ac8 --- /dev/null +++ b/docs/_generated/decision_points/human_impact_2_0_1.md @@ -0,0 +1,19 @@ + +!!! note "Human Impact v2.0.1" + + === "Text" + + Human Impact is a combination of Safety and Mission impacts. + + | Value | Definition | + |:-----|:-----------| + | Low | Safety Impact:(Negligible) AND Mission Impact:(None OR Degraded OR Crippled) | + | Medium | (Safety Impact:Negligible AND Mission Impact:MEF Failure) OR (Safety Impact:Marginal AND Mission Impact:(None OR Degraded OR Crippled)) | + | High | (Safety Impact:Critical AND Mission Impact:(None OR Degraded OR Crippled)) OR (Safety Impact:Marginal AND Mission Impact:MEF Failure) | + | Very High | Safety Impact:Catastrophic OR Mission Impact:Mission Failure | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/human_impact_2_0_1.json" %} + ``` diff --git a/docs/_generated/decision_points/mission_and_well-being_impact.md b/docs/_generated/decision_points/mission_and_well-being_impact.md new file mode 120000 index 00000000..ffa452e7 --- /dev/null +++ b/docs/_generated/decision_points/mission_and_well-being_impact.md @@ -0,0 +1 @@ +mission_and_well-being_impact_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/mission_and_well-being_impact_1_0_0.md b/docs/_generated/decision_points/mission_and_well-being_impact_1_0_0.md new file mode 100644 index 00000000..bfc26462 --- /dev/null +++ b/docs/_generated/decision_points/mission_and_well-being_impact_1_0_0.md @@ -0,0 +1,18 @@ + +!!! note "Mission and Well-Being Impact v1.0.0" + + === "Text" + + Mission and Well-Being Impact is a combination of Mission Prevalence and Public Well-Being Impact. + + | Value | Definition | + |:-----|:-----------| + | Low | Mission Prevalence:Minimal AND Public Well-Being Impact:Minimal | + | Medium | Mission Prevalence:Support AND Public Well-Being Impact:(Minimal OR Material) | + | High | Mission Prevalence:Essential OR Public Well-Being Impact:(Irreversible) | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/mission_and_well-being_impact_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/mission_impact.md b/docs/_generated/decision_points/mission_impact.md new file mode 120000 index 00000000..938009ab --- /dev/null +++ b/docs/_generated/decision_points/mission_impact.md @@ -0,0 +1 @@ +mission_impact_2_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/mission_impact_1_0_0.md b/docs/_generated/decision_points/mission_impact_1_0_0.md new file mode 100644 index 00000000..3b8f858a --- /dev/null +++ b/docs/_generated/decision_points/mission_impact_1_0_0.md @@ -0,0 +1,20 @@ + +!!! note "Mission Impact v1.0.0" + + === "Text" + + Impact on Mission Essential Functions of the Organization + + | Value | Definition | + |:-----|:-----------| + | None | Little to no impact | + | Non-Essential Degraded | 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 | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/mission_impact_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/mission_impact_2_0_0.md b/docs/_generated/decision_points/mission_impact_2_0_0.md new file mode 100644 index 00000000..72aa323f --- /dev/null +++ b/docs/_generated/decision_points/mission_impact_2_0_0.md @@ -0,0 +1,19 @@ + +!!! note "Mission Impact v2.0.0" + + === "Text" + + Impact on Mission Essential Functions of the Organization + + | 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 | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/mission_impact_2_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/public_safety_impact.md b/docs/_generated/decision_points/public_safety_impact.md new file mode 120000 index 00000000..d2071e3b --- /dev/null +++ b/docs/_generated/decision_points/public_safety_impact.md @@ -0,0 +1 @@ +public_safety_impact_2_0_1.md \ No newline at end of file diff --git a/docs/_generated/decision_points/public_safety_impact_2_0_0.md b/docs/_generated/decision_points/public_safety_impact_2_0_0.md new file mode 100644 index 00000000..f23c40af --- /dev/null +++ b/docs/_generated/decision_points/public_safety_impact_2_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Public Safety Impact v2.0.0" + + === "Text" + + A coarse-grained representation of impact to public safety. + + | Value | Definition | + |:-----|:-----------| + | Minimal | Safety Impact:(None OR Minor) | + | Significant | Safety Impact:(Major OR Hazardous OR Catastrophic) | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/public_safety_impact_2_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/public_safety_impact_2_0_1.md b/docs/_generated/decision_points/public_safety_impact_2_0_1.md new file mode 100644 index 00000000..45546a2e --- /dev/null +++ b/docs/_generated/decision_points/public_safety_impact_2_0_1.md @@ -0,0 +1,17 @@ + +!!! note "Public Safety Impact v2.0.1" + + === "Text" + + A coarse-grained representation of impact to public safety. + + | Value | Definition | + |:-----|:-----------| + | Minimal | Safety Impact:Negligible | + | Significant | Safety Impact:(Marginal OR Critical OR Catastrophic) | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/public_safety_impact_2_0_1.json" %} + ``` diff --git a/docs/_generated/decision_points/public_value_added.md b/docs/_generated/decision_points/public_value_added.md new file mode 120000 index 00000000..b185dcb5 --- /dev/null +++ b/docs/_generated/decision_points/public_value_added.md @@ -0,0 +1 @@ +public_value_added_1_0_0.md \ 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 new file mode 100644 index 00000000..63d302cf --- /dev/null +++ b/docs/_generated/decision_points/public_value_added_1_0_0.md @@ -0,0 +1,18 @@ + +!!! note "Public Value Added v1.0.0" + + === "Text" + + How much value would a publication from the coordinator benefit the broader community? + + | Value | Definition | + |:-----|:-----------| + | 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" + + ```json + {% include "../../../data/json/decision_points/public_value_added_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/public_well-being_impact.md b/docs/_generated/decision_points/public_well-being_impact.md new file mode 120000 index 00000000..52bbe1c7 --- /dev/null +++ b/docs/_generated/decision_points/public_well-being_impact.md @@ -0,0 +1 @@ +public_well-being_impact_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/public_well-being_impact_1_0_0.md b/docs/_generated/decision_points/public_well-being_impact_1_0_0.md new file mode 100644 index 00000000..e3802f4c --- /dev/null +++ b/docs/_generated/decision_points/public_well-being_impact_1_0_0.md @@ -0,0 +1,18 @@ + +!!! note "Public Well-Being Impact v1.0.0" + + === "Text" + + A coarse-grained representation of impact to public well-being. + + | Value | Definition | + |:-----|:-----------| + | Minimal | The effect is below the threshold for all aspects described in material. | + | Material | Any one or more of these conditions hold. Physical harm: Does one or more of the following: (a) Causes physical distress or injury to system users. (b) Introduces occupational safety hazards. (c) Reduces and/or results in failure of cyber-physical system safety margins. Environment: Major externalities (property damage, environmental damage, etc.) are imposed on other parties. Financial: Financial losses likely lead to bankruptcy of multiple persons. Psychological: Widespread emotional or psychological harm, sufficient to necessitate counseling or therapy, impact populations of people. | + | Irreversible | Any one or more of these conditions hold. Physical harm: One or both of the following are true: (a) Multiple fatalities are likely.(b) The cyber-physical system, of which the vulnerable componen is a part, is likely lost or destroyed. Environment: Extreme or serious externalities (immediate public health threat, environmental damage leading to small ecosystem collapse, etc.) are imposed on other parties. Financial: Social systems (elections, financial grid, etc.) supported by the software are destabilized and potentially collapse. Psychological: N/A | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/public_well-being_impact_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/report_credibility.md b/docs/_generated/decision_points/report_credibility.md new file mode 120000 index 00000000..549fae08 --- /dev/null +++ b/docs/_generated/decision_points/report_credibility.md @@ -0,0 +1 @@ +report_credibility_1_0_0.md \ 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 new file mode 100644 index 00000000..0d1ed805 --- /dev/null +++ b/docs/_generated/decision_points/report_credibility_1_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Report Credibility v1.0.0" + + === "Text" + + Is the report credible? + + | Value | Definition | + |:-----|:-----------| + | Not Credible | The report is not credible. | + | Credible | The report is credible. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/report_credibility_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/report_public.md b/docs/_generated/decision_points/report_public.md new file mode 120000 index 00000000..1bd15fd2 --- /dev/null +++ b/docs/_generated/decision_points/report_public.md @@ -0,0 +1 @@ +report_public_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/report_public_1_0_0.md b/docs/_generated/decision_points/report_public_1_0_0.md new file mode 100644 index 00000000..2f4a6c79 --- /dev/null +++ b/docs/_generated/decision_points/report_public_1_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Report Public v1.0.0" + + === "Text" + + Is a viable report of the details of the vulnerability already publicly available? + + | Value | Definition | + |:-----|:-----------| + | Yes | A public report of the vulnerability exists. | + | No | No public report of the vulnerability exists. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/report_public_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/safety_impact.md b/docs/_generated/decision_points/safety_impact.md new file mode 120000 index 00000000..e3cfa4d7 --- /dev/null +++ b/docs/_generated/decision_points/safety_impact.md @@ -0,0 +1 @@ +safety_impact_2_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/safety_impact_1_0_0.md b/docs/_generated/decision_points/safety_impact_1_0_0.md new file mode 100644 index 00000000..53f9868c --- /dev/null +++ b/docs/_generated/decision_points/safety_impact_1_0_0.md @@ -0,0 +1,20 @@ + +!!! note "Safety Impact v1.0.0" + + === "Text" + + The safety impact of the vulnerability. + + | Value | Definition | + |:-----|:-----------| + | None | The effect is below the threshold for all aspects described in Minor. | + | Minor | Any one or more of these conditions hold. Physical harm: Physical discomfort for users (not operators) of the system. 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. | + | Major | Any one or more of these conditions hold. Physical harm: Physical distress and injuries for users (not operators) of the system. 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. | + | Hazardous | Any one or more of these conditions hold. Physical harm: Serious or fatal injuries, where fatalities are plausibly preventable via emergency services or other measures. 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 immediate fatalities (Emergency response probably cannot save the victims.) 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" + + ```json + {% include "../../../data/json/decision_points/safety_impact_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/safety_impact_2_0_0.md b/docs/_generated/decision_points/safety_impact_2_0_0.md new file mode 100644 index 00000000..a13fb828 --- /dev/null +++ b/docs/_generated/decision_points/safety_impact_2_0_0.md @@ -0,0 +1,19 @@ + +!!! note "Safety Impact v2.0.0" + + === "Text" + + The safety impact of the vulnerability. (based on IEC 61508) + + | 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. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/safety_impact_2_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/supplier_cardinality.md b/docs/_generated/decision_points/supplier_cardinality.md new file mode 120000 index 00000000..518ef0e7 --- /dev/null +++ b/docs/_generated/decision_points/supplier_cardinality.md @@ -0,0 +1 @@ +supplier_cardinality_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/supplier_cardinality_1_0_0.md b/docs/_generated/decision_points/supplier_cardinality_1_0_0.md new file mode 100644 index 00000000..9dbdc154 --- /dev/null +++ b/docs/_generated/decision_points/supplier_cardinality_1_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Supplier Cardinality v1.0.0" + + === "Text" + + How many suppliers are responsible for the vulnerable component and its remediation or mitigation plan? + + | Value | Definition | + |:-----|:-----------| + | One | There is only one supplier of the vulnerable component. | + | Multiple | There are multiple suppliers of the vulnerable component. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/supplier_cardinality_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/supplier_contacted.md b/docs/_generated/decision_points/supplier_contacted.md new file mode 120000 index 00000000..7a40d514 --- /dev/null +++ b/docs/_generated/decision_points/supplier_contacted.md @@ -0,0 +1 @@ +supplier_contacted_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/supplier_contacted_1_0_0.md b/docs/_generated/decision_points/supplier_contacted_1_0_0.md new file mode 100644 index 00000000..aff63ba8 --- /dev/null +++ b/docs/_generated/decision_points/supplier_contacted_1_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Supplier Contacted v1.0.0" + + === "Text" + + Has the reporter made a good-faith effort to contact the supplier of the vulnerable component using a quality contact method? + + | Value | Definition | + |:-----|:-----------| + | No | The supplier has not been contacted. | + | Yes | The supplier has been contacted. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/supplier_contacted_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/supplier_engagement.md b/docs/_generated/decision_points/supplier_engagement.md new file mode 120000 index 00000000..7a13d88e --- /dev/null +++ b/docs/_generated/decision_points/supplier_engagement.md @@ -0,0 +1 @@ +supplier_engagement_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/supplier_engagement_1_0_0.md b/docs/_generated/decision_points/supplier_engagement_1_0_0.md new file mode 100644 index 00000000..2d3d9d18 --- /dev/null +++ b/docs/_generated/decision_points/supplier_engagement_1_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Supplier Engagement v1.0.0" + + === "Text" + + Is the supplier responding to the reporter’s contact effort and actively participating in the coordination effort? + + | Value | Definition | + |:-----|:-----------| + | 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 not actively participating in the coordination effort. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/supplier_engagement_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/supplier_involvement.md b/docs/_generated/decision_points/supplier_involvement.md new file mode 120000 index 00000000..9f97027b --- /dev/null +++ b/docs/_generated/decision_points/supplier_involvement.md @@ -0,0 +1 @@ +supplier_involvement_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/supplier_involvement_1_0_0.md b/docs/_generated/decision_points/supplier_involvement_1_0_0.md new file mode 100644 index 00000000..3e7504b2 --- /dev/null +++ b/docs/_generated/decision_points/supplier_involvement_1_0_0.md @@ -0,0 +1,18 @@ + +!!! note "Supplier Involvement v1.0.0" + + === "Text" + + What is the state of the supplier’s work on addressing the vulnerability? + + | Value | Definition | + |:-----|:-----------| + | 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. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/supplier_involvement_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/system_exposure.md b/docs/_generated/decision_points/system_exposure.md new file mode 120000 index 00000000..38c20e7b --- /dev/null +++ b/docs/_generated/decision_points/system_exposure.md @@ -0,0 +1 @@ +system_exposure_1_0_1.md \ No newline at end of file diff --git a/docs/_generated/decision_points/system_exposure_1_0_0.md b/docs/_generated/decision_points/system_exposure_1_0_0.md new file mode 100644 index 00000000..4c6e977c --- /dev/null +++ b/docs/_generated/decision_points/system_exposure_1_0_0.md @@ -0,0 +1,18 @@ + +!!! note "System Exposure v1.0.0" + + === "Text" + + The Accessible Attack Surface of the Affected System or Service + + | 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. | + | Unavoidable | Internet or another widely accessible network where access cannot plausibly be restricted or controlled (e.g., DNS servers, web servers, VOIP servers, email servers) | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/system_exposure_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/system_exposure_1_0_1.md b/docs/_generated/decision_points/system_exposure_1_0_1.md new file mode 100644 index 00000000..234fa98a --- /dev/null +++ b/docs/_generated/decision_points/system_exposure_1_0_1.md @@ -0,0 +1,18 @@ + +!!! note "System Exposure v1.0.1" + + === "Text" + + The Accessible Attack Surface of the Affected System or Service + + | 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) | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/system_exposure_1_0_1.json" %} + ``` diff --git a/docs/_generated/decision_points/technical_impact.md b/docs/_generated/decision_points/technical_impact.md new file mode 120000 index 00000000..8418d098 --- /dev/null +++ b/docs/_generated/decision_points/technical_impact.md @@ -0,0 +1 @@ +technical_impact_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/technical_impact_1_0_0.md b/docs/_generated/decision_points/technical_impact_1_0_0.md new file mode 100644 index 00000000..13603ec8 --- /dev/null +++ b/docs/_generated/decision_points/technical_impact_1_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Technical Impact v1.0.0" + + === "Text" + + The technical impact of 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. | + | 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. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/technical_impact_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/utility.md b/docs/_generated/decision_points/utility.md new file mode 120000 index 00000000..73464668 --- /dev/null +++ b/docs/_generated/decision_points/utility.md @@ -0,0 +1 @@ +utility_1_0_1.md \ No newline at end of file diff --git a/docs/_generated/decision_points/utility_1_0_0.md b/docs/_generated/decision_points/utility_1_0_0.md new file mode 100644 index 00000000..0678ec6c --- /dev/null +++ b/docs/_generated/decision_points/utility_1_0_0.md @@ -0,0 +1,18 @@ + +!!! note "Utility v1.0.0" + + === "Text" + + The Usefulness of the Exploit to the Adversary + + | Value | Definition | + |:-----|:-----------| + | Laborious | Virulence:Slow and Value Density:Diffuse | + | Efficient | Virulence:Rapid and Value Density:Diffuse OR Virulence:Slow and Value Density:Concentrated | + | Super Effective | Virulence:Rapid and Value Density:Concentrated | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/utility_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/utility_1_0_1.md b/docs/_generated/decision_points/utility_1_0_1.md new file mode 100644 index 00000000..6ffb2611 --- /dev/null +++ b/docs/_generated/decision_points/utility_1_0_1.md @@ -0,0 +1,18 @@ + +!!! note "Utility v1.0.1" + + === "Text" + + The Usefulness of the Exploit to the Adversary + + | Value | Definition | + |:-----|:-----------| + | Laborious | Automatable:No AND Value Density:Diffuse | + | Efficient | (Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated) | + | Super Effective | Automatable:Yes AND Value Density:Concentrated | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/utility_1_0_1.json" %} + ``` diff --git a/docs/_generated/decision_points/value_density.md b/docs/_generated/decision_points/value_density.md new file mode 120000 index 00000000..d65e392d --- /dev/null +++ b/docs/_generated/decision_points/value_density.md @@ -0,0 +1 @@ +value_density_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/value_density_1_0_0.md b/docs/_generated/decision_points/value_density_1_0_0.md new file mode 100644 index 00000000..c1351297 --- /dev/null +++ b/docs/_generated/decision_points/value_density_1_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Value Density v1.0.0" + + === "Text" + + The concentration of value in the target + + | 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. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/value_density_1_0_0.json" %} + ``` diff --git a/docs/_generated/decision_points/virulence.md b/docs/_generated/decision_points/virulence.md new file mode 120000 index 00000000..e14f67c6 --- /dev/null +++ b/docs/_generated/decision_points/virulence.md @@ -0,0 +1 @@ +virulence_1_0_0.md \ No newline at end of file diff --git a/docs/_generated/decision_points/virulence_1_0_0.md b/docs/_generated/decision_points/virulence_1_0_0.md new file mode 100644 index 00000000..63e7497f --- /dev/null +++ b/docs/_generated/decision_points/virulence_1_0_0.md @@ -0,0 +1,17 @@ + +!!! note "Virulence v1.0.0" + + === "Text" + + The speed at which the vulnerability can be exploited. + + | Value | Definition | + |:-----|:-----------| + | 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. | + | Rapid | Steps 1-4 of the of the kill chain can be reliably automated. If the vulnerability allows remote code execution or command injection, the default response should be rapid. | + + === "JSON" + + ```json + {% include "../../../data/json/decision_points/virulence_1_0_0.json" %} + ``` 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/_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/_includes/helping_out.md b/docs/_includes/helping_out.md new file mode 100644 index 00000000..e869620b --- /dev/null +++ b/docs/_includes/helping_out.md @@ -0,0 +1,63 @@ +# 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. + +!!! 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) + 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 57% rename from doc/md_src_files/09_changelog.md rename to docs/about/changelog.md index fa3ea704..32194d6e 100644 --- a/doc/md_src_files/09_changelog.md +++ b/docs/about/changelog.md @@ -1,24 +1,24 @@ # Changelog ## Version 2.1 Changelog -This section summarizes the changes between SSVC 2.1 and [SSVC version 2.0](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=653459). -The details of what changes were made can be viewed on the SSVC Github under the [SSVC v2.1](https://github.com/CERTCC/SSVC/milestone/2) milestone. +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](https://certcc.github.io/SSVC/ssvc-calc/) which became the basis for CISA's [SSVC Calculator](https://www.cisa.gov/ssvc-calculator) -- Updated Deployer tree to use [*Automatable*](#automatable) instead of [*Utility*](#utility), which reduced the size from 108 leaf nodes to 72. +- 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](#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](#representing-information-for-decisions-about-vulnerabilities) -- Improved description of [*Mission Impact*](#mission-impact) -- Improved consistency of [*Public Safety Impact*](#public-safety-impact) usage throughout the document and tooling -- Improved consistency of [*Human Impact*](#human-impact) usage throughout the document -- Clarified that known default passwords are an example of [*Exploitation*](#exploitation):PoC -- Clarified that unreachable code (as in unused library features) are [_System Exposure_](#system-exposure):small -- Mention DoD MEF definition in [_Mission Impact_](#mission-impact) -- Updated references to [EPSS](https://www.first.org/epss/) to reflect recent publications +- 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](https://github.com/CERTCC/SSVC/actions/workflows/pandoc_html_pdf.yaml) +- 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) @@ -26,8 +26,8 @@ The details of what changes were made can be viewed on the SSVC Github under the ## Version 2 Changelog -This section summarizes the changes between SSVC version 2 and [SSVC version 1.1](https://weis2020.econinfosec.org/wp-content/uploads/sites/8/2020/06/weis20-final6.pdf) 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](https://github.com/CERTCC/SSVC/issues?q=is%3Aissue+is%3Aclosed+project%3ACERTCC%2FSSVC%2F1) closed under the `SSVC v2 Development` project. +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. @@ -47,13 +47,13 @@ Some terms have been adjusted to better align with other usage in the field or b 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*](#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**](#enumerating-vulnerability-management-actions). +“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](#scope) concepts around vulnerability identificatin and disambiguation. +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. @@ -62,24 +62,24 @@ 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*](#public-safety-impact) and [*Situated Safety Impact*](#situated-safety-impact). +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*](#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. +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*](#mission-impact) and [*Situated Safety Impact*](#situated-safety-impact). +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*](#mission-impact) would mitigate a high [*Situated Safety Impact*](#situated-safety-impact) or vice versa. -On the other hand, a low [*Utility*](#utility) or [*System Exposure*](#system-exposure) may mitigate a high mission or well-being impact. +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](#tree-construction-and-customization-guidance) is largely new or revised. -We produced new [software tools](https://github.com/CERTCC/SSVC/tree/main/src) for interacting with SSVC, which are documented in that section. +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](#guidance-on-communicating-results) is largely new. +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. diff --git a/doc/md_src_files/17_contact_us.md b/docs/about/contact_us.md similarity index 60% rename from doc/md_src_files/17_contact_us.md rename to docs/about/contact_us.md index f6fe8e4b..3e740193 100644 --- a/doc/md_src_files/17_contact_us.md +++ b/docs/about/contact_us.md @@ -1,4 +1,3 @@ - # Contact Us Software Engineering Institute @@ -6,4 +5,6 @@ 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) + +{% 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 new file mode 100644 index 00000000..fdd0519e --- /dev/null +++ b/docs/about/contributing.md @@ -0,0 +1,3 @@ +{% include-markdown "../_includes/helping_out.md" %} + +{% 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/docs/about/index.md b/docs/about/index.md new file mode 100644 index 00000000..74f4fc02 --- /dev/null +++ b/docs/about/index.md @@ -0,0 +1,23 @@ +# About SSVC + +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. + + +
+ +- :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-copyright: [Copyright](copyright.md) +- :material-inbox-arrow-down: [Contact Us](contact_us.md) + +
\ No newline at end of file diff --git a/docs/adr/0000-record-architecture-decisions.md b/docs/adr/0000-record-architecture-decisions.md new file mode 100644 index 00000000..fcd64cce --- /dev/null +++ b/docs/adr/0000-record-architecture-decisions.md @@ -0,0 +1,16 @@ +# Record architecture decisions + +* Status: accepted +* Date: 2023-10-16 + +## Context + +We need to record the architectural decisions made on Opinionated Digital Center. + +## Decision + +We will use Architecture Decision Records, as [described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions). + +## Consequences + +See Michael Nygard's article, linked above. diff --git a/docs/adr/0001-use-markdown-architectural-decision-records.md b/docs/adr/0001-use-markdown-architectural-decision-records.md new file mode 100644 index 00000000..2c99e241 --- /dev/null +++ b/docs/adr/0001-use-markdown-architectural-decision-records.md @@ -0,0 +1,43 @@ +# Use Markdown Architectural Decision Records + +Adapted from +[MADR's similar decision record](https://github.com/adr/madr/blob/2.1.2/docs/adr/0000-use-markdown-architectural-decision-records.md). + +* Status: accepted +* Date: 2023-10-16 + +## Context and Problem Statement + +We want to record architectural decisions made in this project. +Which format and structure should these records follow? + +## Considered Options + +* [MADR](https://adr.github.io/madr/) 3.0.0 - The Markdown Architectural Decision Records +* [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) - The first incarnation of the term "ADR" +* [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) - The Y-Statements +* Other templates listed at +* Formless - No conventions for file format and structure + +## Decision Outcome + +Chosen option: "MADR 3.0.0", because + +* Implicit assumptions should be made explicit. + Design documentation is important to enable people understanding the decisions later on. + See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940). +* The MADR format is lean and fits our development style. +* The MADR structure is comprehensible and facilitates usage & maintenance. +* Version 3.0.0 is the latest one available when starting to document ADRs. + +### Positive Consequences + +The ADR are more structured. See especially: +* [MADR-0002 - Do not use numbers in headings](https://github.com/adr/madr/blob/2.1.2/docs/adr/0002-do-not-use-numbers-in-headings.md). +* [MADR-0005 - Use (unique number and) dashes in filenames](https://github.com/adr/madr/blob/2.1.2/docs/adr/0005-use-dashes-in-filenames.md). +* [MADR-0010 - Support categories (in form of subfolders with local ids)](https://github.com/adr/madr/blob/2.1.2/docs/adr/0010-support-categories.md). +* See [full set of MADR ADRs](https://github.com/adr/madr/blob/2.1.2/docs/adr). + +### Negative Consequences + +* Learning curve will be slightly longer. diff --git a/docs/adr/0002-ssvc-decision-points-are-versioned.md b/docs/adr/0002-ssvc-decision-points-are-versioned.md new file mode 100644 index 00000000..4a0d0ae2 --- /dev/null +++ b/docs/adr/0002-ssvc-decision-points-are-versioned.md @@ -0,0 +1,61 @@ +--- +status: accepted +date: 2023-10-17 +deciders: adh, jspring, vssarvepalli, latyzenhaus, cgyarbrough, ehatleback +--- +# SSVC Decision Points are versioned using Semantic Versioning + +## Context and Problem Statement + +A decision point represents a unit of information for use in one or more decisions +As SSVC evolves and grows, we occasionally have the need to modify an existing decision point. +This can happen as we learn more about a particular decision and how a particular decision point is used in practice. +It can also happen as we refine our understanding of the concept that a decision point represents. + +Our expectation is that decision points could go through a number of revisions over time, but that the revisions +should be relatively infrequent after an initial period of refinement. + +Note: This decision addresses the fact that decision points are versioned, but does not address how the version number +is used. We will address that in a separate decision. + + +## Decision Drivers + +* Decision points evolve over time + * new values (options) are added, modified, or removed + * descriptions are updated + +## Considered Options + +* No versioning +* [Semantic versioning](https://semver.org/) +* [CalVer](https://calver.org/) + +## Decision Outcome + +Chosen option: "Semantic versioning" because it conveys the magnitude of changes to decision points, and provides +indication of compatibility expectations between versions. + +- No versioning would be the simplest option, but it would make it difficult to track changes to decision points over time. +- CalVer doesn't reflect the magnitude of changes to decision points, and does not convey much information about +compatibility expectations between versions. +- Semver makes sense for decision point versioning because we don't anticipate them changing much once they go 1.0 + - and typo fixes etc. could just bump the fix version e.g., 1.0.2 -> 1.0.3 + + +### Consequences + +- Maintaining version numbers for decision points will add a small burden to each decision point. +- Semantic versioning will make it easier to track changes to decision points over time. +- Because we don't anticipate frequent changes to decision points, the burden of maintaining version numbers should be minimal. + +### Confirmation + +- JSON schema validation of the Decision Point object will confirm that the version number is a valid semantic version. +- Python unit tests will confirm that the version number is a valid semantic version. + +## More Information + +- [Discussion #289](https://github.com/CERTCC/SSVC/discussions/289) in the SSVC project. +- [Semantic Versioning](https://semver.org/) +- [CalVer](https://calver.org/) \ No newline at end of file diff --git a/docs/adr/0003-ssvc-decision-point-versioning-rules.md b/docs/adr/0003-ssvc-decision-point-versioning-rules.md new file mode 100644 index 00000000..b625d4cc --- /dev/null +++ b/docs/adr/0003-ssvc-decision-point-versioning-rules.md @@ -0,0 +1,93 @@ +--- +status: superseded by [ADR-0006](0006-ssvc-decision-point-versioning-rules.md) +date: 2023-10-17 +deciders: adh, jspring, vssarvepalli, latyzenhaus, cgyarbrough, ehatleback +--- +# SSVC Decision Points Versioning Rules + +## Context and Problem Statement + + +A decision point represents a unit of information for use in one or more decisions +An SSVC "version" might introduce new decision points or new functions (trees) over existing decision points (or both) +As SSVC evolves and grows, we occasionally have the need to modify an existing decision point. +This can happen as we learn more about a particular decision and how a particular decision point is used in practice. +It can also happen as we refine our understanding of the concept that a decision point represents. + +Our expectation is that decision points could go through a number of revisions over time, but that the revisions +should be relatively infrequent after an initial period of refinement. + +Note: This decision addresses the rules for versioning, and depends on the decision to version decision points in the first place. + + +## Decision Drivers + +* Decision points evolve over time + * new values (options) are added, modified, or removed + * descriptions are updated +* Semantic versioning is a well-known and well-understood standard, but we need to define how it applies to decision points. + +## Considered Options + +See SSVC [Discussion #289](https://github.com/CERTCC/SSVC/discussions/289). + +Strictly speaking, Decision Points might not need to be explicitly versioned because they're basically static once introduced. +(Because any semantic change just forks into a new decision point.) +However, for future-proofing purposes we might want to include a key-value pair in the decision point definition to represent a version ID. + +We could establish rules such as +- version 0.x is reserved for pre-support Decision Points and their shorthand key, labels, number of labels, ordering of labels, descriptions, semantics, etc. are all subject to change +- version 1.0 freezes the Decision Point labels, number of labels, and their ordering +- version 1.0.x for x > 0 would be limited to description changes + + +## Decision Outcome + +Chosen option: "Semantic versioning": + +> Given a version number MAJOR.MINOR.PATCH, increment the: +> +> - MAJOR version when you make incompatible API changes +> - MINOR version when you add functionality in a backward compatible manner +> - PATCH version when you make backward compatible bug fixes +> +> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. + +Applied as follows: + + +| Do this... | ...when... | +|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| New Object | A different or new concept is being represented
Note: new objects get new names | +| +1 Major Version | Existing options are _removed_
Option semantics change in a way that older answers are no longer usable
New options are added that divide previous semantics ambiguously
Note: The ability to map old to new semantics is encouraged but not required | +| +0.1 Minor Version | New options are added
Option names are changed while semantics are retained
_AND_ all existing options are retained with compatible semantics | +| +0.0.1 Patch Version | No changes to number of options
No changes to semantics of options
Typo fixes in option names or decision point name | + +Decision Points having a major version of 0 are considered to be pre-support and their shorthand key, labels, number of labels, ordering of labels, descriptions, semantics, etc. are all subject to change. +Because the Major Version is 0 for these decision points, the Minor Version and Fix Version can be used to indicate how +significant a change is by combining the above rules for Major and Minor versions into a single rule for Minor versions. +In other words, a Minor version increment of a 0.x decision point may be used to indicate a change in semantics that +is not backwards compatible. This is not the case for decision points with a Major Version of 1 or greater. + +The lowest supported version of a decision point is 1.0.0. + +### Consequences + +- Maintaining version numbers for decision points according to these rules will add a small burden to each decision point. +- Semantic versioning will make it easier to track changes to decision points over time. +- Because we don't anticipate frequent changes to decision points, the burden of maintaining version numbers should be minimal. +- Decision point versions can move in either direction when used repeatedly in other versioned objects (E.g., a decision model could +use use version 2.1 of a decision point at one time and later revert to using version 1.0 if the 2.1 was found to be problematic). +- Multiple versions of decision points will be "live and available for use" by folks modeling decisions unless explicitly deprecated. +- We think that Decision Points SHOULD have a way to indicate a deprecated status as a means to stave off future regrets. +This implies the need for a way to denote the _status_ of a decision point in addition to its _version_. +Decision Point _status_ will need to be addressed in a separate decision (or decisions) regarding decision point lifecycles. + +### Confirmation + +- The PR process will confirm that the decision point version number is updated according to these rules. + +## More Information + +- [Discussion #289](https://github.com/CERTCC/SSVC/discussions/289) in the SSVC project. +- [Semantic Versioning](https://semver.org/) diff --git a/docs/adr/0004-ssvc-decision-point-groups-are-versioned.md b/docs/adr/0004-ssvc-decision-point-groups-are-versioned.md new file mode 100644 index 00000000..345801ca --- /dev/null +++ b/docs/adr/0004-ssvc-decision-point-groups-are-versioned.md @@ -0,0 +1,55 @@ +--- +# These are optional elements. Feel free to remove any of them. +status: "accepted" +date: 2023-10-31 +deciders: adh, jspring, vssarvepalli, cgyarbrough, latyzenhaus, ehatleback +--- +# Decision Point Groups are Versioned using SemVer + +## Context and Problem Statement + +Decision Point Groups are sets of decision points pinned to specific versions of those decision points. +These groups may change over time. + +For example, the SSVC _Patch Applier_ and _Deployer_ trees have evolved as follows: + +| _Patch Applier_ (SSVC v1) | _Deployer_ (SSVC v2) | _Deployer_ (SSVC v2.1) | +|:-------------------------:|:--------------------------------------------------------:|:-----------------------------------------------------------:| +| Exploitation 1.0.0 | Exploitation 1.0.0 | Exploitation 1.0.0 | +| System Exposure 1.0.0 | System Exposure 1.0.1 | System Exposure 1.0.1 | +| Mission Impact 1.0.0 | Mission Impact 1.0.0
(as input to Human Impact 1.0.0) | Mission Impact 2.0.0
(as input to Human Impact 1.0.0) | +| Safety Impact 1.0.0 | Safety Impact 1.0.0
(as input to Human Impact 1.0.0) | Safety Impact 1.0.0
(as input to Human Impact 1.0.0) | +| - | Automatable 1.0.0
(as input to Utility 1.0.1) | Automatable 1.0.0 | +| - | Value Density 1.0.0
(as input to Utility 1.0.1) | - | + +We need to be able to discriminate between different versions of these groups. + +## Decision Drivers + +- Decision Points change over time +- The composition of decision point groups change over time +- It is important that we can discriminate between versions of decision point groups +- Although technically a Decision Point Group is fully defined by the set of pinned Decision Points it contains +(e.g., any column in the table above), we find it convenient to be able to refer to the group as a whole, and to be +able to discriminate between different versions of the group. + +## Considered Options + +- No versioning +- [Semantic Versioning](https://semver.org/) +- [CalVer](https://calver.org/) + +## Decision Outcome + +Chosen option: "Semantic Versioning", because it conveys the magnitude of changes to decision point groups, and provides +indication of compatibility expectations between versions. + +### Consequences + +- Maintaining version numbers for decision point groups will add a small burden to each decision point group. +- Semantic versioning will make it easier to track changes to decision point groups over time. +- Because we don't anticipate frequent changes to decision point groups, the burden of maintaining version numbers should be minimal. + +## More Information + +- [Github Discussion #303](https://github.com/CERTCC/SSVC/discussions/303) diff --git a/docs/adr/0005-ssvc-decision-point-group-versioning.md b/docs/adr/0005-ssvc-decision-point-group-versioning.md new file mode 100644 index 00000000..f515f1d0 --- /dev/null +++ b/docs/adr/0005-ssvc-decision-point-group-versioning.md @@ -0,0 +1,113 @@ +--- +# These are optional elements. Feel free to remove any of them. +status: "accepted" +date: 2023-10-31 +deciders: adh, jspring, vssarvepalli, cgyarbrough, latyzenhaus, ehatleback +--- +# Decision Point Group Versioning Rules + +## Context and Problem Statement + +[ADR 004](0004-ssvc-decision-point-groups-are-versioned.md) established that Decision Point Groups should be versioned. + +This ADR establishes the rules for versioning Decision Point Groups. + +## Decision Drivers + +(See [ADR 004](0004-ssvc-decision-point-groups-are-versioned.md) for additional context.) + +- Decision Points change over time +- The composition of decision point groups change over time +- It is important that we can discriminate between versions of decision point groups +- Although technically a Decision Point Group is fully defined by the set of + pinned Decision Points it contains, we find it convenient to be able to + refer to the group as a whole, and to be able to discriminate between different versions of the group. + + +## Considered Options + +A number of options were discussed in +[SSVC Discussion #303](https://github.com/CERTCC/SSVC/discussions/303). + +Summarizing that discussion: + +- No versioning +- [Semantic Versioning](https://semver.org/) of SSVC as a whole (status quo) +- [Semantic Versioning](https://semver.org/) of individual decision point groups +- [CalVer](https://calver.org/) + +## Decision Outcome + +Chosen option: "Semantic Versioning of individual decision point groups", +because it conveys the magnitude of changes to decision point groups, and +provides indication of compatibility expectations between versions. + +Implemented as follows: + +The core identity of a decision point group is derived from the pairing of the +_stakeholder role_ and the specific _decision_ being modeled. + +### Create a new object when + +- The stakeholder role and/or the decision being modeled changes. Even if the +set of decision points remains the same, a shift in either stakeholder role or +the decision represents a branching in the version history. + +**Note:** New objects MUST have a new name. + +Otherwise, a change (add, remove) in decision point groups where both the +role and decision being modeled are held constant SHOULD be given a new +version of the existing name according to the following rules. + +### Increment the major version when + +- Conditions for creating a new object are not met, AND + - Adding or removing a decision point entirely, OR + - An existing decision point increments its major version + +### Increment the minor version when + +- Conditions for incrementing the major version are not met, AND +- An existing decision point increments its minor version + +### Increment the patch version when + +- Conditions for incrementing the minor version are not met, AND + - An existing decision point increments its patch version, OR + - The decision point group description changes, OR + - The decision point group name changes + +### Examples + +Assume a decision point group (DPG) named _DPG v1.0.0_, +containing decision points (DP) _A v1.0.0_ and _B v1.3.1_. +In the table below, we show how the Decision Point Group version number changes +as the constituent Decision Points change. + +| DPG Start Version | DP A | DP B | DP C | DPG End Version | +|:-----------------:|:------------------:|:------------------:|:------------------:|:---------------:| +| 1.0.0 | 1.0.0 | 1.3.1 → 1.3.2 | - | 1.0.1 | +| 1.0.1 | 1.0.0 → 1.1.0 | 1.3.2 | - | 1.1.0 | +| 1.1.0 | 1.1.0 | (removed) | 1.0.0 | 2.0.0 | +| 2.0.0 | 1.1.0 | - | 1.0.0 → 2.0.0 | 3.0.0 | + +In row 1, DP B undergoes a patch version increment, which triggers a patch version increment for the DPG. +In row 2, DP A undergoes a minor version increment, which triggers a minor version increment for the DPG. +In row 3, DP B is replaced by DP C, which triggers a major version increment for the DPG. +In row 4, DP C undergoes a major version increment, which triggers a major version increment for the DPG. + +### Consequences + +- Maintaining version numbers for decision point groups will add a small burden to each decision point group. +- Semantic versioning will make it easier to track changes to decision point groups over time. +- Because we don't anticipate frequent changes to decision point groups, the burden of maintaining version numbers should be minimal. +- We are deliberately avoiding using the _name_ of the Decision Point Group as part of the versioning scheme, as +in the motivating example in +[ADR 0004](0004-ssvc-decision-point-groups-are-versioned.md) we shifted the +group name from _Patch Applier_ to _Deployer_, but since the group is still +intended to represent the same _stakeholder role_ and _decision_, we want +to be able to treat name changes as aliases rather than versioning events. + +## More Information + +- [Github Discussion #303](https://github.com/CERTCC/SSVC/discussions/303) diff --git a/docs/adr/0006-ssvc-decision-point-versioning-rules.md b/docs/adr/0006-ssvc-decision-point-versioning-rules.md new file mode 100644 index 00000000..580b4ae0 --- /dev/null +++ b/docs/adr/0006-ssvc-decision-point-versioning-rules.md @@ -0,0 +1,142 @@ +--- +status: accepted +date: 2023-11-01 +deciders: adh, jspring +--- +# SSVC Decision Points Versioning Rules + +## Context and Problem Statement + +A decision point represents a unit of information for use in one or more decisions +An SSVC "version" might introduce new decision points or new functions (trees) over existing decision points (or both) +As SSVC evolves and grows, we occasionally have the need to modify an existing decision point. +This can happen as we learn more about a particular decision and how a particular decision point is used in practice. +It can also happen as we refine our understanding of the concept that a decision point represents. + +Our expectation is that decision points could go through a number of revisions over time, but that the revisions +should be relatively infrequent after an initial period of refinement. + +Note: This decision addresses the rules for versioning, and depends on the decision to version decision points in the first place. + +## Decision Drivers + +* Decision points evolve over time + * new values (options) are added, modified, or removed + * descriptions are updated +* Semantic versioning is a well-known and well-understood standard, but we need to define how it applies to decision points. + +## Considered Options + +See SSVC [Discussion #289](https://github.com/CERTCC/SSVC/discussions/289). + +Strictly speaking, Decision Points might not need to be explicitly versioned because they're basically static once introduced. +(Because any semantic change just forks into a new decision point.) +However, for future-proofing purposes we might want to include a key-value pair in the decision point definition to represent a version ID. + +We could establish rules such as + +* version 0.x is reserved for pre-support Decision Points and their shorthand key, labels, number of labels, ordering of labels, descriptions, semantics, etc. are all subject to change +* version 1.0 freezes the Decision Point labels, number of labels, and their ordering +* version 1.0.x for x > 0 would be limited to description changes + +## Decision Outcome + +Chosen option: "Semantic versioning": + +> Given a version number MAJOR.MINOR.PATCH, increment the: +> +> * MAJOR version when you make incompatible API changes +> * MINOR version when you add functionality in a backward compatible manner +> * PATCH version when you make backward compatible bug fixes +> +> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. + +Applied as follows: + +### Create a new object when + +* A different or new concept is being represented + +**Note**: New objects SHOULD get new names and new keys + +### Increment the Major Version when + +* Criteria for creating a new object are not met, _AND_ + * existing values are removed, _OR_ + * value semantics change in a way that older answers are no longer usable, + _OR_ + * new values are added that divide previous value semantics ambiguously + +**Note**: The ability to map old to new semantics is encouraged but not required + +### Increment the Minor Version when + +Minor version increments imply that existing value semantics are preserved. + +* Criteria for incrementing the Major Version are not met, _AND_ + * new options are added, _OR_ + * value names or keys are changed, _OR_ + * the decision point name is changed + +### Increment the Patch Version when + +Patch version increments imply that existing value number and semantics are +preserved. + +* Criteria for incrementing the Major or Minor Version are not met, _AND_ + * typo fixes in option names or decision point name, _OR_ + * the decision point description changes in a way that does not affect + semantics, _OR_ + * a value description changes in a way that does not affect semantics + +### Pre-Support Decision Points + +Decision Points having a major version of 0 are considered to be pre-support +and their shorthand key, labels, number of labels, ordering of labels, +descriptions, semantics, etc. are all subject to change. + +Because the Major Version is 0 for these decision points, the Minor Version +and Fix Version can be used to indicate how significant a change is by +combining the above rules for Major and Minor versions into a single rule for +Minor versions. +In other words, a Minor version increment of a 0.x decision point may be used +to indicate a change in semantics that is not backwards compatible. +This is not the case for decision points with a Major Version of 1 or greater. + +The lowest _supported_ version of a decision point is 1.0.0. + +### Examples + +We use CVSS Attack Vector (formerly Access Vector) as an example because it +illustrates the ambiguity that can arise when a decision point value is split. + +| Decision Point | Initial Version | New Version | Reason | +|---------------------------------| --------------- |-------------|------------------------------------------------| +| Access Vector | 1.0.0 | 2.0.0 | `remote` split into `network` and `adjacent` | +| Attack (formerly Access) Vector | 2.0.0 | 3.0.0 | `local` split into `physical` and `local` | + +We observe that if the only change was from Access Vector v2.0.0 being +renamed to Attack Vector, then the new version would have been 2.1.0. However, +the change in semantics from Local to Physical and Local is not backwards +compatible, so the new version is 3.0.0. + +### Consequences + +* Maintaining version numbers for decision points according to these rules will add a small burden to each decision point. +* Semantic versioning will make it easier to track changes to decision points over time. +* Because we don't anticipate frequent changes to decision points, the burden of maintaining version numbers should be minimal. +* Decision point versions can move in either direction when used repeatedly in other versioned objects (E.g., a decision model could +use use version 2.1 of a decision point at one time and later revert to using version 1.0 if the 2.1 was found to be problematic). +* Multiple versions of decision points will be "live and available for use" by folks modeling decisions unless explicitly deprecated. +* We think that Decision Points SHOULD have a way to indicate a deprecated status as a means to stave off future regrets. +This implies the need for a way to denote the _status_ of a decision point in addition to its _version_. +Decision Point _status_ will need to be addressed in a separate decision (or decisions) regarding decision point lifecycles. + +### Confirmation + +* The PR process will confirm that the decision point version number is updated according to these rules. + +## More Information + +* [Discussion #289](https://github.com/CERTCC/SSVC/discussions/289) in the SSVC project. +* [Semantic Versioning](https://semver.org/) diff --git a/docs/adr/0007-descriptions-exclude-examples.md b/docs/adr/0007-descriptions-exclude-examples.md new file mode 100644 index 00000000..36699d94 --- /dev/null +++ b/docs/adr/0007-descriptions-exclude-examples.md @@ -0,0 +1,75 @@ +--- +status: "accepted" +date: 2023-11-17 +deciders: adh, jspring +--- +# Object Descriptions Exclude Examples + +## Context and Problem Statement + +In written definitions of a Decision Point, Decision Point +Value, Outcome Group, Outcome Value, or other elements, it is common to +include examples in the text. In terms of documentation, this is a worthy +practice to promote understanding. + +Examples are sometimes timely and need to be updated even though the +underlying concept has not changed. This can lead to unnecessary +versioning of objects. + +## Decision Drivers + +- In the course of modeling CVSS vectors across versions as SSVC decision + points, we have found that concepts change less often than examples. +- Our preference is to minimize version changes to objects unless the + underlying concept has changed. + +## Considered Options + +- Include examples in descriptions of objects. +- Exclude examples from descriptions of objects. + +## Decision Outcome + +Chosen option: "Exclude examples from descriptions of objects", because this +helps to minimize version changes to objects unless the underlying concept +has changed. + +Examples may be included in the documentation text surrounding the object +definition, but not in the object definition itself. + +### Consequences + +- Good, because it reduces the likelihood and frequency of version changes to + objects. +- Good, because it promotes the use of examples in documentation text. +- Bad, because it may make it more difficult to understand the object + definition solely from the object definition itself. + +### Confirmation + +The implementation of this decision is confirmed by the absence of examples +in the object definitions. + +When generating an object definition from a text description, object +creators should look out for phrases like "for example" and "an example of +this is" and exclude the example from the object definition. + +## Pros and Cons of the Options + +### Option 1: Include examples in descriptions of objects + +- Good, because it makes the object definition easier to understand as a standalone + element. +- Bad, because it lengthens the object definition. +- Bad, because it may lead to unnecessary versioning of objects. + +### Option 2: Exclude examples from descriptions of objects + +See [Decision Outcome](#decision-outcome). + +## More Information + +- [ADR-0006](0006-ssvc-decision-point-versioning-rules.md) - SSVC Decision + Point Versioning Rules +- [ADR-0005](0005-ssvc-decision-point-group-versioning.md) - SSVC Decision + Point Group Versioning Rules diff --git a/docs/adr/0008-decision-points-are-ordered-sets.md b/docs/adr/0008-decision-points-are-ordered-sets.md new file mode 100644 index 00000000..df1740be --- /dev/null +++ b/docs/adr/0008-decision-points-are-ordered-sets.md @@ -0,0 +1,128 @@ +--- +status: "proposed" +date: 2024-02-07 +deciders: adh, jspring, ehatleback +consulted: team +--- +# Decision Points are Ordered Sets + +## Context and Problem Statement + +Decision Points are collections of values that can be used to construct an SSVC Decision Model (aka Tree). +We would like to be able to consistently reason about outcomes of a decision given a set of input values. +Doing so may allow us to automate portions of decision model construction and evaluation by asserting +rules about the interaction between decision point values and the outcomes of the decision. + +## Decision Drivers + +* The need to reason about the outcomes of a decision given a set of input values. +* Desire to automate portions of the decision-making process. +* Desire for rules to validate the interaction between decision point values and the outcomes of the decision. + +## Considered Options + +* Decision Point values are ordered sets. +* Decision Point values are unordered sets. + +## Decision Outcome + +Chosen option: "Decision Point values are ordered sets" + +Rationale: An ordered set implies that for a decision set $D$ with $n$ values $d_1, d_2, \ldots, d_n$, we can +assert the relationship $d_1 \leq d_2 \leq \ldots \leq d_n$. + +When combining decision points into a decision model, we can use that relationship to assert rules about the +interaction between decision points. For example, if we have a decision point $D_a$ with values $a_1, a_2, a_3$ +and a decision point $D_b$ with values $b_1, b_2, b_3$, we know that + +- $a_1 \leq a_2 \leq a_3$ +- $b_1 \leq b_2 \leq b_3$ + +We can then extend this reasoning to assert the following relationships in combination: + +(Note that in the following diagram, lower values are at the top and higher values are at the bottom.) + +```mermaid +graph TD + subgraph tier1 + 11[a1, b1] + end + subgraph tier2 + 12[a1, b2] + 21[a2, b1] + end + subgraph tier3 + 13[a1, b3] + 22[a2, b2] + 31[a3, b1] + end + subgraph tier4 + 23[a2, b3] + 32[a3, b2] + end + subgraph tier5 + 33[a3, b3] + end + 11 -->|≤| 12[a1, b2] + 11 -->|≤| 21[a2, b1] + 12 -->|≤| 13[a1, b3] + 21 -->|≤| 22 + 21 -->|≤| 31[a3, b1] + 12 -->|≤| 22[a2, b2] + 22 -->|≤| 23[a2, b3] + 22 -->|≤| 32[a3, b2] + 31 -->|≤| 32 + 13 -->|≤| 23 + 32 -->|≤| 33[a3, b3] + 23 -->|≤| 33 +``` + +In the above diagram, the pairs of values in a tier are incomparable (we don't know which is greater). However, we +can assert that the pairs in the next tier are greater than or equal to the pairs in the previous tier. This +relationship is only possible because we have ordered sets. + +Note that while from the above we can assert that +$(a1,b3) \geq (a1,b2) \geq (a1,b1)$ +and +$(a3,b1) \geq (a2,b1) \geq (a1,b1)$, +we cannot assert that $(a1,b3) \geq (a2,b1)$ or $(a3,b1) \geq (a1,b2)$. The only relationships we can assert are +those that are directly implied by the ordered set relationship (i.e., those shown as arrows in the diagram). + +In combination with an ordered outcome set, then we can say that the outcome of a decision value must be +equal to or between the outcomes of the decision values above and below it. This allows us to generate +default policies that map decision values to outcomes following the graph structure of the decision model. + +### Consequences + +* (Good) This allows us to make inferences about the relationships between sets of decision point values + and the outcomes of the decision. +* (Neutral) Does not fully order all possible decision point value combinations, leaving some relationship combinations + undefined. +* (Neutral) May require additional information to fully define the relationship between decision point values and outcomes + into a policy +* (Neutral) Requires each decision point to have a "direction" (i.e., a way to order the values) which may not be + intuitive in all cases. So far we have found that the natural direction is usually intuitive and most often it is + analogous to "less likely to act" → "more likely to act". +* (Good) Although a sense of direction is required, scaling the values is not. So "None, Few, Many" is just as valid as + a more defined interval scale like "0-4, 4-7, 7-9, 9-10" or a more abstract scale like "Low, Medium, High, Critical"[^1]. + +[^1]: The latter two examples were inspired by CVSS scoring. + + +### Confirmation + +All current decision points are constructed as ordered sets, and the current policy generator tool makes use of that +ordering assumption to generate policies from a set of decision points and outcomes. This isn't so much a feature +we can test for, it's an axiom we use to reason about the decision model. + +However, we *can* evaluate new decision points as they are proposed to ensure that they are ordered sets. + +## More Information + +- Discussion: [Are Decision Points always ordered sets?](https://github.com/CERTCC/SSVC/discussions/290) +- Issues: [#299](https://github.com/CERTCC/SSVC/issues/299), [#403](https://github.com/CERTCC/SSVC/issues/403) +- Relevant prior PRs: [#423](https://github.com/CERTCC/SSVC/pull/423), [#424](https://github.com/CERTCC/SSVC/pull/424) +- [ADR-0009](0009-outcomes-are-ordered-sets.md) - Outcomes are Ordered Sets +- [Partially ordered sets](https://en.wikipedia.org/wiki/Partially_ordered_set) +- [Hasse diagram](https://en.wikipedia.org/wiki/Hasse_diagram) + diff --git a/docs/adr/0009-outcomes-are-ordered-sets.md b/docs/adr/0009-outcomes-are-ordered-sets.md new file mode 100644 index 00000000..e801f2cc --- /dev/null +++ b/docs/adr/0009-outcomes-are-ordered-sets.md @@ -0,0 +1,161 @@ +--- +status: "proposed" +date: 2024-02-07 +--- +# Decision Points are Ordered Sets + +## Context and Problem Statement + +Outcome sets are collections of values that can be used to construct an SSVC Decision Model (aka Tree). +We would like to be able to consistently reason about outcomes of a decision given a set of input values. +Doing so may allow us to automate portions of decision model construction and evaluation by asserting +rules about the interaction between decision point values and the outcomes of the decision. + +## Decision Drivers + +* The need to reason about the outcomes of a decision given a set of input values. +* Desire to automate portions of the decision-making process. +* Desire for rules to validate the interaction between decision point values and the outcomes of the decision. + +## Considered Options + +* Outcome values are ordered sets. +* Outcome values are unordered sets. + +## Decision Outcome + +Chosen option: "Outcome values are ordered sets" + +Rationale: An ordered set implies that for an outcome set $C$ with $n$ values $c_1, c_2, \ldots, c_n$, we can +assert the relationship $c_1 \leq c_2 \leq \ldots \leq c_n$. + +When combining outcomes with a set of decision points into a decision model and policy, we can use that relationship +to assert rules about the resulting policy. + +For example, if we have a decision model consisting of: + +- a decision point $D_a$ with values $a_1, a_2, a_3$ which follows the relationship $a_1 \leq a_2 \leq a_3$ +- a decision point $D_b$ with values $b_1, b_2, b_3$ which follows the relationship $b_1 \leq b_2 \leq b_3$ +- an outcome set $C$ with values $c_1, c_2, c_3, c_4$ which follows the relationship $c_1 \leq c_2 \leq c_3 \leq c_4$ + +We know the following relationships to be true: + +(Note that in the following diagram, lower values are at the top and higher values are at the bottom.) + +```mermaid +--- +title: Partial order of an example decision model +--- +graph TD + subgraph decision point values + 11[a1, b1] + 12[a1, b2] + 21[a2, b1] + 13[a1, b3] + 22[a2, b2] + 31[a3, b1] + 23[a2, b3] + 32[a3, b2] + 33[a3, b3] + end + subgraph outcomes + c1 + c2 + c3 + c4 + end + 11 -->|≤| 12[a1, b2] + 11 -->|≤| 21[a2, b1] + 12 -->|≤| 13[a1, b3] + 21 -->|≤| 22 + 21 -->|≤| 31[a3, b1] + 12 -->|≤| 22[a2, b2] + 22 -->|≤| 23[a2, b3] + 22 -->|≤| 32[a3, b2] + 31 -->|≤| 32 + 13 -->|≤| 23 + 32 -->|≤| 33[a3, b3] + 23 -->|≤| 33 + c1 -->|≤| c2 + c2 -->|≤| c3 + c3 -->|≤| c4 +``` + +And so we can evaluate the validity of a specific policy such as: + +```mermaid +--- +title: Example of a policy that maps decision point values to outcomes according to the partial order above +--- +graph LR + subgraph decision point values + 11[a1, b1] + 12[a1, b2] + 21[a2, b1] + 13[a1, b3] + 22[a2, b2] + 31[a3, b1] + 23[a2, b3] + 32[a3, b2] + 33[a3, b3] + end + subgraph outcomes + c1 + c2 + c3 + c4 + end + 11 --> c1 + 21 --> c1 + 31 --> c2 + 32 --> c3 + 33 --> c4 + 23 --> c3 + 22 --> c3 + 13 --> c2 + 12 --> c2 +``` + +This generalizes to the following: + +Given a specific tuple of decision point values $T_1 = (a_i, b_j, \ldots)$ and a second tuple +of decision point values $T_2 = (a_k, b_l, \ldots)$ where $T_1 \leq T_2$, then the outcome of the decision +$Outcome(T_1)$ must be equal to or less than the outcome $Outcome(T_2)$ of any tuple of decision point values $T_2$. + +$Outcome(T_1) \leq Outcome(T_2)$ when $T_1 \leq T_2$. + +This allows us to generate default policies that map decision values to outcomes following the graph structure of the +decision model. + +### Consequences + +* (Good) This allows us to make inferences about the relationships between sets of decision point values + and the outcomes of the decision. +* (Neutral) Does not fully order all possible decision point value combinations, leaving some relationship combinations + undefined. +* (Neutral) May require additional information to fully define the relationship between decision point values and outcomes + into a policy +* (Neutral) Requires each outcome set to have a "direction" (i.e., a way to order the values) which may not be + intuitive in all cases. So far we have found that the natural direction is usually intuitive and most often it is + analogous to "less likely to act" → "more likely to act". +* (Good) Although a sense of direction is required, scaling the values is not. So "Defer, Scheduled, Out-of-Band, Immediate" + is just as valid as a more Service Level Expectation (SLE) oriented "1 hour, 1 day, 1 week, 1 month". + + +### Confirmation + +All current outcomes are constructed as ordered sets, and the current policy generator tool makes use of that +ordering assumption to generate policies from a set of decision points and outcomes. This isn't so much a feature +we can test for, it's an axiom we use to reason about the decision model. + +However, we *can* evaluate new outcome sets as they are proposed to ensure that they are ordered sets. + +## More Information + +- Discussion: [Are Decision Points always ordered sets?](https://github.com/CERTCC/SSVC/discussions/290) +- Issues: [#299](https://github.com/CERTCC/SSVC/issues/299), [#403](https://github.com/CERTCC/SSVC/issues/403) +- Relevant prior PRs: [#423](https://github.com/CERTCC/SSVC/pull/423), [#424](https://github.com/CERTCC/SSVC/pull/424) +- [ADR-0008](0008-decision-points-are-ordered-sets.md) - Decision Points are Ordered Sets +- [Partially ordered sets](https://en.wikipedia.org/wiki/Partially_ordered_set) +- [Hasse diagram](https://en.wikipedia.org/wiki/Hasse_diagram) + diff --git a/docs/adr/0010-outcome-sets-are-separate-from-decision-point-groups.md b/docs/adr/0010-outcome-sets-are-separate-from-decision-point-groups.md new file mode 100644 index 00000000..3073af84 --- /dev/null +++ b/docs/adr/0010-outcome-sets-are-separate-from-decision-point-groups.md @@ -0,0 +1,115 @@ +--- +status: "accepted" +date: 2024-02-08 +deciders: adh, jspring +consulted: team +--- +# Outcome Sets are Separate from Decision Point Groups + +## Context and Problem Statement + +Should the outcome set be included in a decision model (tree) definition? + +While a decision point group and their combinations of values define the structure of a tree, an Outcome Set defines +the possible labels of each leaf node. However, in order to decide what labels are appropriate for a leaf node, one +must also be given a policy that maps each input combination (specific decision point values) to a specific outcome +(drawn from an outcome set). But both the policy and the outcome set are actually stakeholder-specific. + +The example trees we provide are at best a guess at a reasonable policy for SSVC adopters for each of the decisions we +chose to model. And they also make assumptions about the process that the decision supports. So we assumed that +suppliers have four options for priority. And we assigned outcome labels to leaf nodes based on what seemed reasonable +to us at the time. But we must acknowledge that (a) stakeholders might have an arbitrary number of categories for +prioritization (2, 3, 4, 5, ...), and (b) they may have wide variation in what combinations are given which priority. + + +## Decision Drivers + +* There was some discussion during the development of [ADR 0005](0005-ssvc-decision-point-group-versioning.md) about + whether the outcome set should be included in the tree definition. + +## Considered Options + +* Include the outcome set in the decision point group definition. +* Omit the outcome set from the decision point group definition. + +## Decision Outcome + +Chosen option: "Omit the outcome set from the decision point group definition", because the outcome set is +stakeholder-specific and not part of the decision point group's (aka _the tree's_) identity. + +We need to define a few terms here: + +- a _decision point group_ is a set of decision points that are used to model a decision. The combinations of the decision + points' values define the structure of the decision model (aka _tree_). +- an _outcome set_ is the set of possible outcomes for a decision model. Each leaf node of a tree is labeled with an + outcome from the outcome set. +- a _policy_ is a mapping from specific combinations of decision point values to specific outcomes from the outcome set. + +A decision point group fully defines the structure of a decision model (tree). The outcome set and the policy are +both stakeholder-specific. + +Two examples for illustrative purposes: + +1. Two organizations could use the same decision point group to model the same decision, but + one has a 3-category outcome set and the other has a 4-category outcome set. The two organizations would be using the + same decision model but with different outcome sets. This inherently leads to different policies. +2. Two organizations might use both the same decision point group and the same outcome set, but still have different + policies mapping the specific decision point value combinations to different outcome values. + +In both cases, the structure of the decision model (tree) is the same, but the resulting policies are different. + +If we were to include both the outcome set and the policy in the decision point group definition, then both examples +would lead to the conclusion that the two organizations' decision models are different, when in fact they have modeled +the same decision in the same structure, only differing in their policy application. + +If we were to include the outcome set but not the policy in the decision point group definition, then the first example +would appear to be "different" whereas the second example would appear to be "the same". This also seems misleading. + +For completeness, it is not possible to include the policy without the outcome set, since the policy depends on both +the decision point group and the outcome set. + +Therefore, the decision point group's (aka _the tree's_) identity omits both the outcome set and its specific mapping to +the tree structure. The thing we're asserting is that the structure of the tree (as defined by its constituent decision +points and their specific versions) is invariant to the above, therefore the tree's identity omits both the outcome set +and its specific mapping to the tree structure. + + +### Consequences + +* Good, because we can avoid decision point group versioning events due to changes in the outcome set or policy. +* Good, because SSVC users can share decision point groups as decision models without needing to share their specific + outcome sets or policies. +* Bad, because the decision point group definition does not fully specify the decision model including the policy. + +### Confirmation + +This decision is confirmed by the fact that decision point groups are versioned independently of outcome sets and policies. + +## Pros and Cons of the Options + +### Include the outcome set in the decision point group definition. + +Including the outcome set in the decision point group definition would mean that the decision model (tree) changes +whenever the outcome set changes. This would lead to a large number of versioning events for decision point groups +whenever the outcome set changes, even if the structure of the decision model (tree) remains the same. + +* Good, because the combination of decision points and outcome sets would be fully specified, and users would only + need to establish their own policy to use the decision model. +* Bad, because the decision model (tree) would change whenever the outcome set changes, even if the structure of the + decision model (tree) remains the same. For example, the same structure with a 3-category outcome set and a 4-category + outcome set would be considered different decision models. + +Furthermore, including both the outcome group _and_ the policy in the decision point group definition would mean that the +decision model (tree) version would change whenever the policy changes, even if the structure of the decision model (tree) and +the outcome set both remained the same. + +* Good, because the decision model (tree) would be fully specified and would not depend on any external factors. +* Bad, because the decision model (tree) would change whenever the policy changes, even if the structure of the + decision model (tree) and the outcome set both remained the same. +* Bad, because the number of versioning events for decision models would be large. + +## More Information + +- Issue [#354](https://github.com/CERTCC/SSVC/issues/354) - Create ADR about Outcome Sets are not included in Decision Point Groups +- Discussion [#303](https://github.com/CERTCC/SSVC/discussions/303#discussioncomment-6926935) - Defining tree versions +- [ADR-0005](0005-ssvc-decision-point-group-versioning.md) - SSVC Decision Point Group Versioning 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/_template.md b/docs/adr/_template.md new file mode 100644 index 00000000..f4da6f8c --- /dev/null +++ b/docs/adr/_template.md @@ -0,0 +1,79 @@ +--- +# These are optional elements. Feel free to remove any of them. +status: "{proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)}" +date: {YYYY-MM-DD when the decision was last updated} +deciders: {list everyone involved in the decision} +consulted: {list everyone whose opinions are sought (typically subject-matter experts); and with whom there is a two-way communication} +informed: {list everyone who is kept up-to-date on progress; and with whom there is a one-way communication} +--- +# {short title of solved problem and solution} + +## Context and Problem Statement + +{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. + You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.} + + +## Decision Drivers + +* {decision driver 1, e.g., a force, facing concern, …} +* {decision driver 2, e.g., a force, facing concern, …} +* … + +## Considered Options + +* {title of option 1} +* {title of option 2} +* {title of option 3} +* … + +## Decision Outcome + +Chosen option: "{title of option 1}", because +{justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}. + + +### Consequences + +* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …} +* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …} +* … + + +### Confirmation + +{Describe how the implementation of/compliance with the ADR is confirmed. E.g., by a review or an ArchUnit test. + Although we classify this element as optional, it is included in most ADRs.} + + +## Pros and Cons of the Options + +### {title of option 1} + + +{example | description | pointer to more information | …} + +* Good, because {argument a} +* Good, because {argument b} + +* Neutral, because {argument c} +* Bad, because {argument d} +* … + +### {title of other option} + +{example | description | pointer to more information | …} + +* Good, because {argument a} +* Good, because {argument b} +* Neutral, because {argument c} +* Bad, because {argument d} +* … + + +## More Information + +{You might want to provide additional evidence/confidence for the decision outcome here and/or + document the team agreement on the decision and/or + define when/how this decision the decision should be realized and if/when it should be re-visited. +Links to other decisions and resources might appear here as well.} \ No newline at end of file diff --git a/docs/adr/index.md b/docs/adr/index.md new file mode 100644 index 00000000..eb58185e --- /dev/null +++ b/docs/adr/index.md @@ -0,0 +1,41 @@ +# SSVC Decision Records + +We have adopted the use of [Markdown Any Decision Records](https://adr.github.io/madr/) +to document significant decisions made in the development of SSVC. Below is a list of all +the decision records that have been made. + +!!! warning "See repository for authoritative source of decision records" + + While we include these records in the site for reference, the authoritative source + for these records, including their current adoption status, is the + [SSVC GitHub repository](https://github.com/CERTCC/SSVC/tree/main/docs/adr). + +## Accepted Records + +- [0000 - Record architecture decisions](0000-record-architecture-decisions.md) +- [0001 - Use Markdown Architectural Decision Records](0001-use-markdown-architectural-decision-records.md) +- [0002 - SSVC Decision Points are versioned using Semantic Versioning](0002-ssvc-decision-points-are-versioned.md) +- [0004 - SSVC Decision Point Groups are Versioned using SemVer](0004-ssvc-decision-point-groups-are-versioned.md) +- [0005 - SSVC Decision Point Group Versioning Rules](0005-ssvc-decision-point-group-versioning.md) +- [0006 - SSVC Decision Points Versioning Rules](0006-ssvc-decision-point-versioning-rules.md) +- [0007 - Object Descriptions Exclude Examples](0007-descriptions-exclude-examples.md) +- [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 + +- None + +## Superseded Records + +- [0003 - SSVC Decision Points Versioning Rules](0003-ssvc-decision-point-versioning-rules.md) + +## Deprecated Records + +- None + +## Records with non-standard statuses + +- None 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/docs/howto/acuity_ramp.md b/docs/howto/acuity_ramp.md new file mode 100644 index 00000000..13e4a2be --- /dev/null +++ b/docs/howto/acuity_ramp.md @@ -0,0 +1,139 @@ +# Acuity Ramp + +!!! question inline end "Why _Acuity_? Isn't this a _Maturity_ Model?" + + The _acuity ramp_ concept is similar to the idea of a _maturity model_, but the term _maturity_ carries a sort of + moral bias in the sense that it has an implied "good" direction from "immature" to "mature". + + _Acuity_ has a more neutral connotation, and represents the ability to perceive the world in more detail. + In our usage, _Acuity_ as a dimension is more akin to the idea of resolution in the imagery/photography sense. + + Given the choice between a lower-resolution and a higher-resolution decision point, stakeholders should choose the + one that is most appropriate for both their decision and context. It is not inherently better to use a + higher-resolution decision point, and it is not inherently worse to use a lower-resolution decision point. + +An SSVC _acuity ramp_ is a concept that describes a series of decision functions that are increasingly more detailed and +complex while addressing the same decision. The idea is that a decision maker can start with a simple decision model and +then, as their needs, resources, or abilities change, they can gather and analyze more or different data to understand +their environment with more acuity. + +## Acuity Tradeoffs + +In Cybersecurity Threat and Vulnerability analysis, as with most decision-making processes, decision makers must +balance trade-offs between the volume, quality, or detail of the information they use and the cost of gathering and +analyzing that information. +There are many good reasons that decision makers might choose to use a lower resolution indicator that is readily +available over a higher resolution indicator that comes at a high cost in terms of time, money, or effort. + +One way to think about the tradeoffs in acuity is to consider the cost or difficulty of gathering and analyzing data. +Some vulnerability information is readily available for free as a public resource. +Other information is available for purchase, for example as a subscription to a threat intelligence feed. +Still other information is only available if you set up a system to collect and manage it yourself, such as an internal +asset management system. +For direct cost tradeoffs, one might conduct a cost-benefit analysis of whether the additional acuity provides value +more than its cost. Sometimes, tradeoffs are not directly cost-based. + +The quality and readiness for use of the information can also vary. Structured, low resolution public data might be +easier to incorporate into a decision model than unstructured data that requires a lot of manual analysis. +At the CERT/CC, we have observed otherwise high quality threat intelligence provided as PDF files with threat indicators +embedded as screenshots of text, which would be difficult to extract and use in a decision model. + +Another tradeoff is that sometimes one decision point can serve as a close-enough proxy for another decision point that +is more costly or difficult to acquire. For example, in a given deployment context, +[_Value Density_](../reference/decision_points/value_density.md) might be more readily discerned than +[_Mission Impact_](../reference/decision_points/mission_impact.md) for some stakeholders because it's easier to +count how many of something there are than to estimate the impact of a loss of specific instances of the thing. +Alternately, information about _Value Density_ might be available from another source, such as a CVSS v4 scoring provider, +whereas _Mission Impact_ might require a more detailed understanding of the stakeholder's mission and environment. +An organization might start with _Value Density_ as a proxy for _Mission Impact_ and then, as they develop a better +understanding of their environment, they could replace _Value Density_ with _Mission Impact_ in their decision model. + + +## An Acuity Ramp in Action + +The _acuity ramp_ idea is a way to show how a stakeholder could "grow into" their desired decision function as their +data collection and analysis capabilities increase. We demonstrate this with the following example. + +!!! example "An Acuity Ramp for a Growing System Deployer Organization" + + A system deployer organization with few initial resources might start with a simple decision model that only includes a custom + `IN_KEV` decision point. The `IN_KEV` decision point would be a simple binary indicator of whether a vulnerability + has been added to CISA's [Known Exploited Vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) + ([KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)) catalog. Because this information is free, + publicly available, and because it is a simple binary indicator, it is easy to gather and analyze even for a very + small organization. + + The following table shows how the organization might expand their decision model as they grow in capability. + + | Acutiy Level | Tree | + | --- | --- | + | 1 | ```[IN_KEV]``` | + | 2 | ```[EXPLOITATION_1]``` | + | 3 | ```[EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1]``` | + | 4 | ```[EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1, AUTOMATABLE_2]``` | + | 5 | ```[EXPLOITATION_1, SYSTEM_EXPOSURE_1_0_1, AUTOMATABLE_2, MISSION_IMPACT_2, SAFETY_IMPACT_1]``` + + !!! tip "Acuity Levels are Stakeholder-Specific" + + This example is demonstrating the _concept_ of _acuity levels_ in SSVC adoption. We are specifically + _not_ saying that there are 5 levels of acuity in SSVC; in principle this concept could be applied to any number + of levels (including just one). In practice, the number of levels necessary would be a stakeholder-specific implementation choice, so + there is no inherent meaning to the "Acuity Levels" shown here outside the context of this example. + + The remainder of this example shows one path the organization might take to grow their decision model + according to the table above. + + ### Improved Exploit Awareness (Acuity Level 2) + + As the organization becomes more capable of gathering and analyzing data, they might start collecting their own + data on exploitation, allowing them to move to a more detailed decision model that replaces the binary `IN_KEV` + decision point with the trinary `EXPLOITATION_1` decision point. For example, they might incorporate data from the + [Exploit Database](https://www.exploit-db.com/) or the + [Exploit Prediction Scoring System](https://www.first.org/epss/) ([EPSS](https://www.first.org/epss/)) + into their decision model. + + {% include-markdown "../_generated/decision_points/exploitation_1_0_0.md" %} + + ### Improved Asset Management (Acuity Level 3) + + As they continue to develop their internal asset management capabilities, they might find they have enough + asset data to reflect the degree to which a system is exposed to the internet, allowing them to + incorporate the `SYSTEM_EXPOSURE_1_0_1` decision point into their decision model. + + {% include-markdown "../_generated/decision_points/system_exposure_1_0_1.md" %} + + ### Improved Threat and Vulnerability Analysis (Acuity Level 4) + + Over time, the organization's threat and vulnerability analysis capabilities might reach a point where they can + begin to collect data on the degree to which a vulnerability is automatable, allowing them to incorporate the + `AUTOMATABLE_1` decision point into their decision model. + This decision point might be informed by data from the + [National Vulnerability Database](https://nvd.nist.gov/) ([NVD](https://nvd.nist.gov/)) + or by translating CVSS v3 or v4 scores into a value for this decision point. + + {% include-markdown "../_generated/decision_points/automatable_2_0_0.md" %} + + ### Improved Mission and Safety Impact Understanding (Acuity Level 5) + + Now that the deployer organization has been at this for a while, they might have a better understanding of the + degree to which a vulnerability impacts both their mission and public safety, allowing them to incorporate the + `MISSION_IMPACT_2` and `SAFETY_IMPACT_1` decision points into their decision model. + + {% include-markdown "../_generated/decision_points/mission_impact_2_0_0.md" %} + {% include-markdown "../_generated/decision_points/safety_impact_1_0_0.md" %} + + In this way, the organization can grow into a more detailed decision model as their understanding and capabilities improve. + + +## Conclusion + +The _acuity ramp_ concept is a way to show how a stakeholder could "grow into" their desired decision function as their +data collection and analysis capabilities improve. It is a way to show how a decision model can be adapted to the +context of the decision maker, and how the decision maker can make trade-offs between the cost of gathering information +and the quality of the decision they are able to make. + +The example above is just a single illustration of the _acuity ramp_ concept. There are many other ways that an +organization might evolve their decision model from a simple starting point toward a more detailed decision model for +any particular decision. Substituting one decision point for another, adding decision points over time, or even +customizing decision points to better fit the organization's specific context are all ways that an organization might +grow from a simple decision model to a more robust one. diff --git a/docs/howto/bootstrap/_steps_table.md b/docs/howto/bootstrap/_steps_table.md new file mode 100644 index 00000000..01c6e98e --- /dev/null +++ b/docs/howto/bootstrap/_steps_table.md @@ -0,0 +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, 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/collect.md b/docs/howto/bootstrap/collect.md new file mode 100644 index 00000000..53381718 --- /dev/null +++ b/docs/howto/bootstrap/collect.md @@ -0,0 +1,143 @@ +# Data Operations + +!!! note inline end + + The diagram below shows two kinds of data emanating from the Data Operations process: _Vulnerability Data_ and _Environment Data_. + Vulnerability Data is data about the vulnerability itself, such as the technical impact or exploit availability. + Environment Data is data about the environment in which the vulnerable systems exist, such as network topology or system criticality. + We generally expect that Environment Data will be more stable than Vulnerability Data, but that is not always the case. + +While the actual collection of operational data is outside the scope of SSVC, it is an important part of any implementation +of the process. +SSVC is designed to be flexible enough to accommodate a variety of data collection methods. +The [Data Mapping](prepare.md) step defines the data that is needed to assign a value to each decision point. +The Data Operations process collects that data so that it can be used to assign values to decision points in the +[Use SSVC](use.md) step. + +We include a feedback loop on the data collection node to indicate that it is expected to be a continuous process. + +```mermaid +flowchart LR + subgraph dmp[Data Mapping] + dd[/Data Definition/] + end + subgraph do[Data Operations] + cd[Collect Data] + vd[/Vulnerability Data/] + ed[/Environment Data/] + dt[\Available Data/] + end + dd --> cd + cd --> cd + cd --> vd + cd --> ed + vd --> dt + ed --> dt +``` + +!!! example + + Having defined a data map that translates certain values from specific threat feeds to the _Exploitation_ decision + point values _PoC_ or _Active_, an organization maintains a subscription to those threat feeds and collects the + data from them on a continuous basis. + They also write a script that parses the data from the threat feeds and applies the data map to assign a value to + the _Exploitation_ decision point. + +## Guidance for Evidence Gathering + +To answer each of these decision points, a stakeholder should, as much as possible, have a repeatable evidence +collection and evaluation process. +However, we are proposing decisions for humans to make, so evidence collection and evaluation is not totally automatable. +That caveat notwithstanding, some automation is possible. + +!!! example "Evidence of Exploitation" + + For example, whether exploitation modules are available in ExploitDB, Metasploit, or other sources is straightforward. + We hypothesize that searching Github and Pastebin for exploit code can be captured in a script. + A supplier or deployer could then define [*Exploitation*](../../reference/decision_points/exploitation.md) to take the value of [*PoC*](../../reference/decision_points/exploitation.md) if + there are positive search results for a set of inputs derived from the CVE entry in at least one of these venues. + At least, for those vulnerabilities that are not “automatically” PoC-ready, such as on-path attackers for TLS or network + replays. + + +Some of the decision points require a substantial upfront analysis effort to gather risk assessment or organizational +data. +However, once gathered, this information can be efficiently reused across many vulnerabilities and only refreshed +occasionally. + +!!! example "Evidence of Mission Impact" + + An obvious example of this is the [Mission Impact](../../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 System Exposure" + + [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 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 +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 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 + [*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. + +!!! 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. + + +!!! example "Using Defaults" + + Applying these defaults to the [deployer decision model](../deployer_tree.md) + + - *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/index.md b/docs/howto/bootstrap/index.md new file mode 100644 index 00000000..95042e6c --- /dev/null +++ b/docs/howto/bootstrap/index.md @@ -0,0 +1,24 @@ +# Bootstrapping an SSVC Process from Scratch + +Using SSVC to prioritize vulnerability response requires a few steps. The steps are: + +!!! note inline end "Bootstrapping SSVC Overview" + + ```mermaid + flowchart + start([Start]) + prep[Prepare to use SSVC] + dataops[Data Operations] + runtime[Use SSVC] + r[Vulnerability Response] + start --> prep + prep --> dataops + dataops --> runtime + runtime --> r + r --> dataops + ``` + +{% include-markdown "howto/bootstrap/_steps_table.md" %} + +We cover each of these in the following sections, starting with [Prepare to Use SSVC](prepare.md). +If you want to skip ahead to the full process, see [Bootstrapping SSVC Summary](summary.md). \ No newline at end of file diff --git a/docs/howto/bootstrap/prepare.md b/docs/howto/bootstrap/prepare.md new file mode 100644 index 00000000..710aab40 --- /dev/null +++ b/docs/howto/bootstrap/prepare.md @@ -0,0 +1,373 @@ +# Prepare to Use SSVC + +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 +--- +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] + dm[/Data Map/] + policy[Policy Development] + p[/Policy/] + end + dcd --> outcomes + dcd --> governance + governance --> governance + outcomes --> decisionpoints + dcd --> decisionpoints + decisionpoints --> dataeng + outcomes --> policy + decisionpoints --> policy + policy --> p + dataeng --> dm +``` + +We will go through each step in detail. + +## Choose a Decision to Model + +!!! example inline end + + Decisions we have modeled with SSVC include: + + - [Patch Supplier Prioritization](../supplier_tree.md) + - [Patch Deployer Prioritization](../deployer_tree.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. +SSVC is designed to help you make decisions about how to respond to a vulnerability. +In the SSVC documentation, we provide a number of example decisions that you might want to make. +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}} + d[/Decision/] + end + dcd --> d +``` + +## Define Outcomes + +!!! 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_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_. + +Once you have chosen a decision to model, you need to define the outcomes for that decision. +An outcome is the result of making a decision. +Outcomes are often tailored specifically to the stakeholder context in which the decision is being made. +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/] + end + subgraph outcomes [Define Outcomes] + oc1[/Use available
outcome sets?\] + dos{{Define Outcome Sets}} + oss[\Outcome Sets/] + cos{{Choose Outcome Set}} + os[/Outcome Set/] + end + d --> oc1 + oc1 -->|y| oss + oc1 -->|n| dos + dos --> oss + cos --> os + oss --> cos +``` + +!!! example + + Imagine two different Service Providers, each of which is responsible for managing vulnerabilities in their + respective environments. + One Service Provider might use a 5-tier incident response model, and so might define their outcome set as: + _Severity 1_, _Severity 2_, _Severity 3_, _Severity 4_, and _Severity 5_. + Another Service Provider might only have three tiers, and so might define their outcome set as: + _High_, _Medium_, and _Low_. + So even though both Service Providers are making the same prioritization decision about their response to the same, + vulnerability, they can use different outcome sets. + +## Define Inputs + +Once you know what decision you want to make and what the possible outcomes are, you need to define the information you need to make that decision. +A decision usually requires more than one piece of information. +SSVC organizes this information into decision points. +A single decision point enumerates a set of options for a particular aspect of the decision. +We have defined a number of decision points in the [SSVC documentation](../../reference/decision_points/index.md). +You can choose from these decision points, or you can define your own decision points to meet your needs. + +Whether you choose from the existing decision points or define your own, the set of decision points you use to make a +decision is called a Decision Point Set. + +```mermaid +--- +title: Inputs Definition Process +--- +flowchart LR + subgraph dd[Choose Decision] + d[/Decision/] + end + subgraph do[Define Outcomes] + oc[/Outcome Set/] + end + + subgraph decisionpoints [Define Inputs] + dp1[/Use available
decision points?\] + ddp{{Define Decision Points}} + dpt[\Decision Points/] + cdp{{Choose Decision Points}} + dps[/Decision Point Set/] + end + oc --> dp1 + d --> dp1 + + dp1 -->|y| dpt + dp1 -->|n| ddp + ddp --> dpt + dpt --> cdp + cdp --> dps +``` + +!!! example + + A medical device manufacturer has specific regulatory requirements for how they respond to vulnerabilities. + As an organization, they have divided their product line into three categories: regulated devices, non-regulated devices, and support services. + Vulnerability reports for regulated devices are handled differently than vulnerability reports for + non-regulated devices. Also, vulnerability reports for support services are handled differently than vulnerability + reports for devices of any kind because support services are covered by medical privacy regulations in addition to + device safety regulations. So, the medical device manufacturer might define a decision point called _Regulated_ with + the values _Regulated Device_, _Non-Regulated Device_, and _Support Service_. + + +## Define Policy + +So far, you have chosen a decision to model, defined the possible outcomes for that decision, and defined the information you need to make that decision. +Now, you need to define the policy you want to use to make that decision. +A policy is a function that takes a set of decision point values as input and returns an outcome as output. +While we often choose to represent policies as decision trees, they can be represented in other ways as well. +In fact, we find that it is often useful to represent policies in tabular form, for example as a CSV file. +We have provided a number of example policies in the [SSVC documentation](../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/] + end + subgraph di [Define Inputs] + dps[/Decision Point Set/] + end + subgraph policy [Policy Development] + dfp{{Define Policy}} + p[/Policy/] + end + oc --> dfp + dps --> dfp + dfp --> p +``` + +!!! example + + A small bank has a policy that they must deploy patches within 48 hours of release if the vulnerability affects systems + that could lead to customer data being exposed. They examine the example [Deployer Prioritization](../supplier_tree.md) + decision model and decide that both the outcome set and the decision point set that define the structure of the + decision model are appropriate for their needs. They map the 48 hour requirement to the _Immediate_ outcome, because + it essentially represents their highest priority response. + However, they notice that the specific policy given in the [Deployer Prioritization](../supplier_tree.md) + example—that is, the mapping from decision point values to outcomes—is not appropriate for their needs + because it has too few _Immediate_ outcomes to suit their policy. + Therefore, the bank decides to reuse the same decision point set and outcome set but define their own policy. + +## 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/] + end + subgraph dataeng [Data Mapping] + dd1[/Use existing data?\] + dpm[/Data Map/] + dp2d{{Map Decision Points to Data}} + dd{{Define Data}} + ddf[/Data Definition/] + end + dps --> dd1 + dps --> dp2d + dd1 -->|y| ddf + dd1 -->|n| dd + dd --> ddf + ddf --> dp2d + dp2d --> dpm +``` + +!!! example + + A Software-as-a-Service Provider differentiates its service levels into three categories: silver, gold, and platinum. + In the Define Inputs step, they defined a custom decision point called _Service Level_ with the values + _Silver_, _Gold_, and _Platinum_. + Now, they need to define a data map that will assign a value to the _Service Level_ decision point. + The data they need to assign a value to the _Service Level_ decision point originates in the service level + agreement (SLA) for each service. + These SLAs are stored in a database. + They decide to write a script that will query the database for the SLA for each service and assign a value to the + _Service Level_ decision point based on the SLA. + As these SLAs do not change very often, they decide to run the script once a day and store the results in a file. + 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 new file mode 100644 index 00000000..409c7fe6 --- /dev/null +++ b/docs/howto/bootstrap/summary.md @@ -0,0 +1,118 @@ +# Bootstrapping SSVC Summary + +Using SSVC to prioritize vulnerability response requires a few steps. The steps are: + +{% include-markdown "howto/bootstrap/_steps_table.md" %} + +We covered each of these in the previous sections, see the links in the table above for more information. + +The diagram below shows the complete process of using SSVC. + + +```mermaid +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}} + oss[\Outcome Sets/] + cos{{Choose Outcome Set}} + os[/Outcome Set/] + end + l5((1)) + subgraph decisionpoints [Define Inputs] + dp1[/Use available
decision points?\] + ddp{{Define Decision Points}} + dpt[\Decision Points/] + cdp{{Choose Decision Points}} + dps[/Decision Point Set/] + end + l6((1)) + subgraph dataeng [Data Mapping] + dd1[/Use existing data?\] + dpm[/Data Map/] + dp2d{{Map Decision Points to Data}} + 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] + vd[/Vulnerability Data/] + ed[/Environment Data/] + dt[\Available Data/] + +end +subgraph runtime [Use SSVC] + mdp[[Apply Decision Point Mapping to Data]] + dp[/Decision Point Values/] + ap[[Apply Policy]] + oc[/Outcome/] +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 +oc1 -->|n| dos +dp1 -->|y| dpt +dp1 -->|n| ddp +dd1 -->|y| ddf +dd1 -->|n| dd +ddp --> dpt +dos --> oss +dpt --> cdp +cdp --> dps +cos --> os +oss --> cos +l7 --> dfp +os --> dfp +os --> dp1 +l5 --> dp1 +d --> dp1 +dps --> dp2d +dp2d --> dpm +dps --> dfp +dpm --> mdp +dd --> ddf +ddf --> dp2d +ddf --> cd +cd --> cd +cd --> vd +cd --> ed +vd --> dt +ed --> dt +dt --> mdp +mdp --> dp +dfp --> p +p --> ap +dp --> ap +ap --> oc +oc --> r +r --> l1((2)) +l2((2)) --> cd +l6 --> dd1 +``` + diff --git a/docs/howto/bootstrap/use.md b/docs/howto/bootstrap/use.md new file mode 100644 index 00000000..cbf9a4db --- /dev/null +++ b/docs/howto/bootstrap/use.md @@ -0,0 +1,220 @@ +# Use SSVC + +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 +flowchart LR + subgraph pd[Policy Development] + p[/Policy/] + end + subgraph dmp[Data Mapping] + dm[/Data Map/] + end + subgraph do[Data Operations] + vd[/Vulnerability Data/] + ed[/Environment Data/] + end + subgraph runtime [Use SSVC] + mdp[[Apply Decision Point Mapping to Data]] + dp[/Decision Point Values/] + ap[[Apply Policy]] + oc[/Outcome/] + end + dm --> mdp + vd --> mdp + ed --> mdp + mdp --> dp + p --> ap + dp --> ap + ap --> oc +``` + + +!!! example + + A government agency has a need to prioritize vulnerability response as part of their vulnerability management process. + Certain vulnerabilities require special handling as a matter of government policy, and the agency wants to make sure + that they are not overlooked. + + The agency completed the [preparation steps](prepare.md) and has defined the decision, the outcome set, and the + decision points and values they want to use. + Because of some special requirements for government agencies, they chose to use a custom outcome set that more closely + matches their existing process. + These same requirements also led them to define a decision function based on a custom selection of existing decision + points. + They've mapped their agency policy to a decision policy that assigns specific decision point values to specific outcomes. + They have also enumerated the data they need to inform the relevant decision point values. + The agency has a process for collecting the data they need, and they have collected the data for a particular + vulnerability. + Now they are ready to use SSVC to decide how to respond to a vulnerability. + + Taking the data they have collected, they first combine it with the data map to produce a set of decision point values. + Then they apply the policy to the decision point values to produce an outcome. + The outcome is a prioritization decision that they can use to inform their response to the vulnerability. + +## Respond to Vulnerabilities + +The actual response to vulnerabilities is outside the scope of SSVC. +But since SSVC is intended to support the vulnerability response process, we include a node to indicate that the +vulnerability response process is the ultimate consumer of the prioritization decision. +We also include a feedback loop from the response node to the data operations node to indicate that the response +process may generate new data that can be used to inform future prioritization decisions. + +```mermaid +flowchart LR + use[Use SSVC] + r[Vulnerability Response] + dataops[Data Operations] + use --> r + r --> dataops + dataops --> use +``` + +!!! example + + Different organizations will have different vulnerability response processes. + The government agency in the previous example might need to notify system owners of the vulnerability and + track other information about the vulnerability for reporting and auditing purposes. + 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 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. + +## 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](../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](../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 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. + +### JSON 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. + +- 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. + +!!! info "Deriving a Decision Point JSON key-value pair" + + Each element of `choices` should be an object that is a key-value pair of `decision point`:`value`, + where the term `decision point` is a string derived from the name of the decision point as follows: + + - Start with the decision point name as given in [Likely Decision Points and Relevant Data](../../reference/decision_points/index.md). + - Remove any text in parentheses (and the parentheses themselves). + - Remove colon characters, if any (`:`). + - Convert the string to [lower camel case](https://en.wikipedia.org/wiki/Camel_case) by lowercasing the string, capitalizing any letter after a space, and removing all spaces. + + The `value` term is derived the same way as `decision point` except start with the value name as given in the relevant decision point subsection of [Likely Decision Points and Relevant Data](../../reference/decision_points/index.md). + + +### Partial or Incomplete Information + +What an analyst knows about a vulnerability may not be complete. +However, the vulnerability management community may still benefit from partial information. +In particular, suppliers and coordinators who might not know everything a deployer knows can still provide benefit to deployers by sharing what partial information they do know. +A second benefit to providing methods for communicating partial information is the reduction of bottlenecks or barriers to information exchange. +A timely partial warning is better than a complete warning that is too late. + +The basic guidance is that the analyst should communicate all of the vulnerability's possible states, to the best of the analyst's knowledge. +If the analyst knows nothing, all states are possible. + +!!! 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. + +!!! example "When Some Values Are Known (But Others Are Not)" + + 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" %} + + 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. + +## Information Changes Over Time + +Vulnerability management decisions are dynamic, and may change over time as the available information changes. +Information changes are one reason why SSVC decisions should always be timestamped. +SSVC decision points have different temporal properties. +Some, such as [Utility](../../reference/decision_points/utility.md), are mostly static. +For [Utility](../../reference/decision_points/utility.md) to change, the market penetration or deployment norms of a vulnerable component would have to meaningfully change. +Some, such as [Exploitation](../../reference/decision_points/exploitation.md), may change quickly but only in one direction. + +!!! 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 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. + +### 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. +These frequencies can be customized, as the update frequency is directly related to the organization's tolerance for the risk that the information is out of date. +As discussed in [Tree Construction and Customization Guidance](../tree_customization.md), risk tolerance is unique to each organization. +Risk tolerance and risk appetite are primarily reflected in the priority labels (that is, decisions) encoded in the SSVC decision tree, but information polling frequency is also a risk tolerance decision and each organization may choose different time values. + +| Decision Point | Suggested Polling Frequency | +|--------------------------------------------------------------------------------|-----------------------------| +| [*Exploitation*](../../reference/decision_points/exploitation.md) | every 1 day | +| [*Technical Impact*](../../reference/decision_points/technical_impact.md) | never (should be static per vulnerability) | +| [*Utility*](../../reference/decision_points/utility.md) | every 6 months | +| [*Public Safety Impact*](../../reference/decision_points/public_safety_impact.md) | every 1 year | + + +### 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. +Vulnerability response analysts should keep such change logs as well. +Similar to logging practices recommended for incident response [@nist800-61r2], such practices make the process less error-prone and facilitate after-action reviews. diff --git a/docs/howto/coordination_intro.md b/docs/howto/coordination_intro.md new file mode 100644 index 00000000..ebcb0a90 --- /dev/null +++ b/docs/howto/coordination_intro.md @@ -0,0 +1,33 @@ +# 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'](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 +[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. + +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 [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 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..b85dd4cd --- /dev/null +++ b/docs/howto/coordination_triage_decision.md @@ -0,0 +1,115 @@ +# 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 + +{% 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 new file mode 100644 index 00000000..68853bc0 --- /dev/null +++ b/docs/howto/deployer_tree.md @@ -0,0 +1,146 @@ +# Prioritizing Patch Deployment + +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" %} + +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. + +!!! 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 + + +{{ read_csv('deployer-options.csv') }} \ No newline at end of file diff --git a/docs/howto/index.md b/docs/howto/index.md new file mode 100644 index 00000000..b3331037 --- /dev/null +++ b/docs/howto/index.md @@ -0,0 +1,75 @@ +# Using SSVC + +!!! tip inline end "Prerequisites" + + The [Using SSVC](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 [Learning SSVC](../tutorials/index.md) section. + [Understanding SSVC](../topics/index.md) provides necessary background detail. + For technical reference, see [Reference](../reference/index.md). + + + +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*) + + - THEN priority is *scheduled*. + + +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**. + +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. + +
+ +- :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) +- :material-hand-saw: [Customizing SSVC](tree_customization.md) +- :material-slope-uphill: [Acuity Ramp](acuity_ramp.md) + +
diff --git a/docs/howto/publication_decision.md b/docs/howto/publication_decision.md new file mode 100644 index 00000000..c9320a7e --- /dev/null +++ b/docs/howto/publication_decision.md @@ -0,0 +1,271 @@ +# Coordinator Publication Decision + +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" + + The publication decision is always a decision at a point in time. + As discussed in [Guidance on Communicating Results](bootstrap/use.md), a SSVC decision may change over time as the inputs to that decision change. + A decision to publish cannot be revoked, since the publication is likely to be archived or at least remembered. + However, a decision to not publish is a decision not to publish at the time the decision was made. + It is not a decision never to publish in the future. + + 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. + +!!! example "CERT/CC Publication Decision Outcomes Over Time" + + 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. + + +## Coordinator Publication Decision Points + +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)). + +- [*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. + + + + + + +|fix ready| e1 + si -->|cooperative| e2 + si -->|uncooperative/
unresponsive| e3 + va1[Value
Added] + va2[Value
Added] + va3[Value
Added] + e1 -->|none| va1 + e1 -->|PoC| va2 + e1 -->|active| va3 + va4[Value
Added] + va5[Value
Added] + va6[Value
Added] + e2 -->|none| va4 + e2 -->|PoC| va5 + e2 -->|active| va6 + va7[Value
Added] + va8[Value
Added] + va9[Value
Added] + e3 -->|none| va7 + e3 -->|PoC| va8 + e3 -->|active| va9 + + p1[Publish] + p2[Don't Publish] + p3[Don't Publish] + + p4[Publish] + p5[Don't Publish] + p6[Don't Publish] + + p7[Publish] + p8[Publish] + p9[Don't Publish] + + p10[Publish] + p11[Don't Publish] + p12[Don't Publish] + + p13[Publish] + p14[Don't Publish] + p15[Don't Publish] + + p16[Publish] + p17[Publish] + p18[Don't Publish] + + p19[Publish] + p20[Don't Publish] + p21[Don't Publish] + + p22[Publish] + p23[Publish] + p24[Don't Publish] + + p25[Publish] + p26[Publish] + p27[Don't Publish] + + va1 -->|precedence| p1 + va1 -->|ampliative| p2 + va1 -->|limited| p3 + + va2 -->|precedence| p4 + va2 -->|ampliative| p5 + va2 -->|limited| p6 + + va3 -->|precedence| p7 + va3 -->|ampliative| p8 + va3 -->|limited| p9 + + va4 -->|precedence| p10 + va4 -->|ampliative| p11 + va4 -->|limited| p12 + + va5 -->|precedence| p13 + va5 -->|ampliative| p14 + va5 -->|limited| p15 + + va6 -->|precedence| p16 + va6 -->|ampliative| p17 + va6 -->|limited| p18 + + va7 -->|precedence| p19 + va7 -->|ampliative| p20 + va7 -->|limited| p21 + + va8 -->|precedence| p22 + va8 -->|ampliative| p23 + va8 -->|limited| p24 + + va9 -->|precedence| p25 + va9 -->|ampliative| p26 + va9 -->|limited| p27 +``` +--> + +### Table of Values + + +{{ read_csv('coord-publish-options.csv') }} + diff --git a/docs/howto/supplier_tree.md b/docs/howto/supplier_tree.md new file mode 100644 index 00000000..380a1177 --- /dev/null +++ b/docs/howto/supplier_tree.md @@ -0,0 +1,100 @@ +# Prioritizing Patch Creation + +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" %} + + + + +### Table of Values + + +{{ read_csv('supplier-options.csv') }} diff --git a/doc/md_src_files/07_04_tree_customization.md b/docs/howto/tree_customization.md similarity index 86% rename from doc/md_src_files/07_04_tree_customization.md rename to docs/howto/tree_customization.md index 3cf61e8b..35016ecd 100644 --- a/doc/md_src_files/07_04_tree_customization.md +++ b/docs/howto/tree_customization.md @@ -1,25 +1,43 @@ -## Tree Construction and Customization Guidance +# Modeling Other Decisions 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. +## Use Existing Decision Points Where Possible + We suggest that the decision points, their definitions, and the decision values should not be customized. -Different vulnerability management teams inevitably think of topics such as [*Utility*](#utility) to the adversary in slightly different ways. +Different vulnerability management teams inevitably think of topics such as [Utility](../reference/decision_points/utility.md) to the adversary in slightly different ways. However, a key contribution of SSVC is enabling different teams to communicate about their decision process. In order to clearly communicate differences in the process, the decision points that factor into the process need to be the same between different teams. A stakeholder community may come together and, if there is broad consensus, add or change decision points. -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. +## Customizing a Decision Model + +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. +### Customizing for Risk Appetite + A team's risk appetite is reflected directly by the priority labels for each combination of decision values. -For example, a vulnerability with [no or minor](#public-safety-impact) [*Public Safety Impact*](#public-safety-impact), [total](#technical-impact) [*Technical Impact*](#technical-impact), and [efficient](#utility) [*Utility*](#utility) might be handled with [*scheduled*](#supplier-decisions) priority by one team and [*out-of-cycle*](#supplier-decisions) priority by another. +For example, a vulnerability with +[no or minor](../reference/decision_points/public_safety_impact.md) +[*Public Safety Impact*](../reference/decision_points/public_safety_impact.md), +[total](../reference/decision_points/technical_impact.md) +[*Technical Impact*](../reference/decision_points/technical_impact.md), +and [efficient](../reference/decision_points/utility.md) +[Utility](../reference/decision_points/utility.md) +might be handled with +[*scheduled*](../howto/deployer_tree.md) +priority by one team and +[*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. @@ -37,7 +55,7 @@ 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 Concerns Decision tree construction methods must address five significant concerns: - feature selection @@ -46,7 +64,7 @@ Decision tree construction methods must address five significant concerns: - parsimony - versioning -#### Feature selection +### 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. @@ -58,18 +76,19 @@ If nothing else, this means analysts are spending time gathering evidence to mak 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 +### 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 +### 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 + 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. @@ -98,12 +117,12 @@ This sort of customization is often the simplest way to adjust the importance of 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 +### 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](https://semver.org/spec/v2.0.0.html). -### Sharing Trees With Others +## 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: @@ -116,7 +135,7 @@ In these and other scenarios, there are two scopes to consider: 1. Decision Point Scope 2. Decision Tree Scope -#### Decision Point Scope +### Decision Point Scope Each decision point defined in this document has a characteristic scope, either *stakeholder-agnostic* or *stakeholder-specific*. @@ -125,22 +144,22 @@ One might think of them as global facts that form the background context in whic Nearly all stakeholders should agree on the assignment of specific values to these decision points. - **Stakeholder-specific decision points** are expected to be contextual to some set of stakeholders. Information about a stakeholder-specific decision point can still be inherited by other stakeholders using the same tree. -For example in the corporate CSIRT scenario above, the [*System Exposure*](#system-exposure) value might be consistent across all subsidiaries for a centrally managed service. +For example in the corporate CSIRT scenario above, the [*System Exposure*](../reference/decision_points/system_exposure.md) value might be consistent across all subsidiaries for a centrally managed service. We generally consider the following decision points to be *stakeholder-agnostic*: -- [*Exploitation*](#exploitation) -- [*Technical Impact*](#technical-impact) -- [*Automatable*](#automatable) +- [*Exploitation*](../reference/decision_points/exploitation.md) +- [*Technical Impact*](../reference/decision_points/technical_impact.md) +- [*Automatable*](../reference/decision_points/automatable.md) On the contrary, we consider the following decision points to be *stakeholder-specific*: -- [*Value Density*](#value-density) -- [*Utility*](#utility) -- [*Safety Impact*](#safety-impact) -- [*Public Safety Impact*](#public-safety-impact) -- [*Situated Safety Impact*](#situated-safety-impact) -- [*Mission Impact*](#mission-impact) -- [*Human Impact*](#human-impact) -- [*System Exposure*](#system-exposure) +- [*Value Density*](../reference/decision_points/value_density.md) +- [Utility](../reference/decision_points/utility.md) +- [*Safety Impact*](../reference/decision_points/safety_impact.md) +- [*Public Safety Impact*](../reference/decision_points/public_safety_impact.md) +- [*Situated Safety Impact*](../reference/decision_points/safety_impact.md) +- [*Mission Impact*](../reference/decision_points/mission_impact.md) +- [*Human Impact*](../reference/decision_points/human_impact.md) +- [*System Exposure*](../reference/decision_points/system_exposure.md) We anticipate that most custom decision points created by stakeholders for themselves or a constituency will be of the *stakeholder-specific* variety. Examples of these sorts of custom decision points include @@ -151,7 +170,7 @@ E.g., a financial institution might have a very low tolerance for changes to a t - 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 +### Decision Tree Scope Two kinds of modifications are possible at the decision tree level. diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 00000000..c6faf6d3 --- /dev/null +++ b/docs/index.md @@ -0,0 +1,53 @@ +# Stakeholder-Specific Vulnerability Categorization + +SSVC stands for A 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 finders, vendors, coordinators, deployers, and others. + + +## Where to go from here + +We have organized the SSVC documentation into four main sections: + +
+ +- :material-television-shimmer:{ .lg .middle } __Get Started with SSVC__ + + --- + + Get started learning about SSVC and how it can help you prioritize vulnerabilities. + This section is intended for people who are new to SSVC. + + [:octicons-arrow-right-24: Learning SSVC](tutorials/index.md) + +- :material-clipboard-check:{ .lg .middle } __SSVC How To__ + + --- + + Start using SSVC in your organization today with step-by-step instructions. + This section is intended for people who are already familiar with SSVC and want to start using it. + + [:octicons-arrow-right-24: SSVC How To](howto/index.md) + +- :fontawesome-solid-book:{ .lg .middle } __Learn More about SSVC__ + + --- + + Dig deeper to understand the SSVC methodology and how it works. + This section is intended for people who are already familiar with SSVC and want to learn more. + + [:octicons-arrow-right-24: Understanding SSVC](topics/index.md) + +- :material-book-open-page-variant:{ .lg .middle } __SSVC Reference__ + + --- + + Reference documentation for SSVC. + This section is intended for people who are already familiar with SSVC and want to look up specific details. + + [:octicons-arrow-right-24: Reference](reference/index.md) + +
+ + +{% include-markdown "_includes/helping_out.md" heading-offset=1 %} diff --git a/docs/javascripts/mathjax.js b/docs/javascripts/mathjax.js new file mode 100644 index 00000000..7e48906a --- /dev/null +++ b/docs/javascripts/mathjax.js @@ -0,0 +1,19 @@ +window.MathJax = { + tex: { + inlineMath: [["\\(", "\\)"]], + displayMath: [["\\[", "\\]"]], + processEscapes: true, + processEnvironments: true + }, + options: { + ignoreHtmlClass: ".*|", + processHtmlClass: "arithmatex" + } +}; + +document$.subscribe(() => { + MathJax.startup.output.clearCache() + MathJax.typesetClear() + MathJax.texReset() + 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/code/analyze_csv.md b/docs/reference/code/analyze_csv.md new file mode 100644 index 00000000..1f47e1ab --- /dev/null +++ b/docs/reference/code/analyze_csv.md @@ -0,0 +1,4 @@ +# SSVC CSV Analyzer + +::: ssvc.csv_analyzer + diff --git a/docs/reference/code/doctools.md b/docs/reference/code/doctools.md new file mode 100644 index 00000000..edd3b5e0 --- /dev/null +++ b/docs/reference/code/doctools.md @@ -0,0 +1,4 @@ +# Doctools + +::: ssvc.doctools + diff --git a/docs/reference/code/index.md b/docs/reference/code/index.md new file mode 100644 index 00000000..726664c0 --- /dev/null +++ b/docs/reference/code/index.md @@ -0,0 +1,9 @@ +# SSVC Code Documentation + +This section provides documentation for the SSVC Python modules. +These include: + +- [CSV Analyzer](analyze_csv.md) +- [Policy Generator](policy_generator.md) +- [Outcomes](outcomes.md) +- [Doctools](doctools.md) \ No newline at end of file diff --git a/docs/reference/code/outcomes.md b/docs/reference/code/outcomes.md new file mode 100644 index 00000000..f1a2d15c --- /dev/null +++ b/docs/reference/code/outcomes.md @@ -0,0 +1,5 @@ +# Outcome Values and Outcome Groups + +::: ssvc.outcomes.base + +::: ssvc.outcomes.groups diff --git a/docs/reference/code/policy_generator.md b/docs/reference/code/policy_generator.md new file mode 100644 index 00000000..fa6e8477 --- /dev/null +++ b/docs/reference/code/policy_generator.md @@ -0,0 +1,9 @@ +# SSVC Policy Generator Tool + +The SSVC Policy Generator is a Python object that generates an SSVC decision +policy (a decision tree) from a set of input parameters. + +It is intended to be used as a library, for example within a Jupyter notebook. + + +::: ssvc.policy_generator \ No newline at end of file diff --git a/docs/reference/decision_points/automatable.md b/docs/reference/decision_points/automatable.md new file mode 100644 index 00000000..9b74a09b --- /dev/null +++ b/docs/reference/decision_points/automatable.md @@ -0,0 +1,67 @@ +# Automatable + +{% include-markdown "../../_generated/decision_points/automatable.md" %} + +!!! tip "See also" + + Automatable combines with [Value Density](./value_density.md) to inform + [Utility](./utility.md) + + +*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](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.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.md) 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 [@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](../../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*" + + *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/compound_decision_points.md b/docs/reference/decision_points/compound_decision_points.md new file mode 100644 index 00000000..cca71dfe --- /dev/null +++ b/docs/reference/decision_points/compound_decision_points.md @@ -0,0 +1,10 @@ +# Compound Decision Points + +For notational convenience we will sometimes combine multiple decision points into a single compound decision point. + +Examples of compound decision points include: + +- [Human Impact](human_impact.md) +- [Public Safety Impact](public_safety_impact.md) +- [Utility](utility.md) + diff --git a/docs/reference/decision_points/exploitation.md b/docs/reference/decision_points/exploitation.md new file mode 100644 index 00000000..58b398c2 --- /dev/null +++ b/docs/reference/decision_points/exploitation.md @@ -0,0 +1,49 @@ +# Exploitation + +{% include-markdown "../../_generated/decision_points/exploitation.md" %} + +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* 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* 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. + 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* + + +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. + +{% include-markdown "../../_includes/_scrollable_table.md" heading-offset=1 %} + + +{{ read_csv('cwe/possible-cwe-with-poc-examples.csv') }} + +--- \ No newline at end of file diff --git a/docs/reference/decision_points/human_impact.md b/docs/reference/decision_points/human_impact.md new file mode 100644 index 00000000..a8a22036 --- /dev/null +++ b/docs/reference/decision_points/human_impact.md @@ -0,0 +1,48 @@ +# Human Impact + +{% include-markdown "../../_generated/decision_points/human_impact.md" %} + +!!! tip "See also" + + *Human Impact* is a combination of [Safety Impact](./safety_impact.md) and + [Mission Impact](./mission_impact.md) + +Note: This is a compound decision point[^1], therefore it is a notational convenience. + +*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. +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 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. +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](../../howto/bootstrap/use.md). + + +## Prior Versions + +{% include-markdown "../../_generated/decision_points/human_impact_2_0_0.md" %} + +{% include-markdown "../../_generated/decision_points/mission_and_well-being_impact_1_0_0.md" %} diff --git a/docs/reference/decision_points/index.md b/docs/reference/decision_points/index.md new file mode 100644 index 00000000..ec64f9a7 --- /dev/null +++ b/docs/reference/decision_points/index.md @@ -0,0 +1,55 @@ +# Likely Decision Points and Relevant Data + +!!! note inline end "Feedback Welcome" + + We made every effort to put forward informed and useful decision frameworks with wide applicability, + but the goal of this documentation 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. + Please submit feedback to the [GitHub repository](https://github.com/CERTCC/SSVC/issues). + +We propose the following decision points and associated values should be a +factor when making decisions about +vulnerability prioritization. +We emphasize that these descriptions are hypotheses to be further tested and +validated. + +We propose satisfactory decision points for vulnerability management in the next +sections, in alphabetical order. +Each decision point page includes advice on gathering information about the +decision point. +[SSVC using Current Information Sources](../../topics/information_sources.md) +provides some +suggestions about how existing sources of information about vulnerabilities can +be used to collate responses to these +decision points. + +!!! note "Decision Point Values are Ordered Sets" + + The values for each decision point are ordered sets, meaning that the order + of the values is significant. The ordering of the values is intended to + reflect the relative importance of the values, with the first value being the + least important and the last value being the most important. By requiring + ordered sets, we can apply consistency checks that ensure that the outcome priority + of a set of decision point values is greater than or equal to the outcome priority of + another set of decision point values if the first set of values is greater than or equal to + the second set of values in every dimension. + +!!! question "What determines the ordering?" + + The relevant dimension to which the ordering for both decision points and + outcomes applies can be different for different decision points and outcomes. + Sometimes this is a "better" or "worse" dimension, but it seems to generalize to + a "more likely to act" or "less likely to act" of dimension. + +!!! 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. diff --git a/doc/md_src_files/05_07_mission_impact.md b/docs/reference/decision_points/mission_impact.md similarity index 72% rename from doc/md_src_files/05_07_mission_impact.md rename to docs/reference/decision_points/mission_impact.md index ada009e5..ca2a05c7 100644 --- a/doc/md_src_files/05_07_mission_impact.md +++ b/docs/reference/decision_points/mission_impact.md @@ -1,5 +1,11 @@ -## Mission Impact -> Impact on Mission Essential Functions of the Organization +# Mission Impact + +{% include-markdown "../../_generated/decision_points/mission_impact.md" %} + +!!! tip "See also" + + Mission Impact combines with [Safety Impact](./safety_impact.md) to inform + [Human Impact](./human_impact.md) 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,16 +25,8 @@ 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 +## 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. @@ -37,5 +35,9 @@ 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 + +{% include-markdown "../../_generated/decision_points/mission_impact_1_0_0.md" %} diff --git a/docs/reference/decision_points/public_safety_impact.md b/docs/reference/decision_points/public_safety_impact.md new file mode 100644 index 00000000..1f26a47d --- /dev/null +++ b/docs/reference/decision_points/public_safety_impact.md @@ -0,0 +1,22 @@ +# Public Safety Impact + +{% include-markdown "../../_generated/decision_points/public_safety_impact.md" %} + +!!! tip "See also" + + - [Safety Impact](./safety_impact.md) + +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. +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. +- _Minimal_ is when none do. + +## Prior Versions + +{% include-markdown "../../_generated/decision_points/public_safety_impact_2_0_0.md" %} + +{% include-markdown "../../_generated/decision_points/public_well-being_impact_1_0_0.md" %} 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..03507837 --- /dev/null +++ b/docs/reference/decision_points/public_value_added.md @@ -0,0 +1,12 @@ +# Public Value Added + +{% 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* 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/report_credibility.md b/docs/reference/decision_points/report_credibility.md new file mode 100644 index 00000000..f508f7cd --- /dev/null +++ b/docs/reference/decision_points/report_credibility.md @@ -0,0 +1,78 @@ +# Report Credibility + +{% include-markdown "../../_generated/decision_points/report_credibility.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. + +## 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. + +!!! note Credibility Definition + + 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. + + diff --git a/docs/reference/decision_points/report_public.md b/docs/reference/decision_points/report_public.md new file mode 100644 index 00000000..5f02a81e --- /dev/null +++ b/docs/reference/decision_points/report_public.md @@ -0,0 +1,3 @@ +# Report Public + +{% include-markdown "../../_generated/decision_points/report_public.md" %} diff --git a/doc/md_src_files/05_06_safety_impact.md b/docs/reference/decision_points/safety_impact.md similarity index 72% rename from doc/md_src_files/05_06_safety_impact.md rename to docs/reference/decision_points/safety_impact.md index e1c8af50..41cd2eb4 100644 --- a/doc/md_src_files/05_06_safety_impact.md +++ b/docs/reference/decision_points/safety_impact.md @@ -1,7 +1,15 @@ -## Safety Impact -> Safety Impacts of Affected System Compromise +# Safety Impact -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. +{% include-markdown "../../_generated/decision_points/safety_impact.md" %} + +!!! tip "See also" + + - Safety Impact combines with [Mission Impact](./mission_impact.md) to + inform [Human Impact](./human_impact.md). + - [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) 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. @@ -219,20 +205,14 @@ resiliency --> -### 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 +### Situated Safety Impact -| Value | Definition | -| :--- | :--------- | -| Minimal | Safety Impact of None or Minor | -| Significant | Safety Impact of Major, Hazardous, or Catastrophic | +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. -### Situated Safety Impact +## Prior Versions -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. +{% include-markdown "../../_generated/decision_points/safety_impact_1_0_0.md" %} diff --git a/docs/reference/decision_points/supplier_cardinality.md b/docs/reference/decision_points/supplier_cardinality.md new file mode 100644 index 00000000..ef55c8bf --- /dev/null +++ b/docs/reference/decision_points/supplier_cardinality.md @@ -0,0 +1,3 @@ +# Supplier Cardinality + +{% include-markdown "../../_generated/decision_points/supplier_cardinality.md" %} diff --git a/docs/reference/decision_points/supplier_contacted.md b/docs/reference/decision_points/supplier_contacted.md new file mode 100644 index 00000000..7a3d9d38 --- /dev/null +++ b/docs/reference/decision_points/supplier_contacted.md @@ -0,0 +1,10 @@ +# Supplier Contacted + +{% include-markdown "../../_generated/decision_points/supplier_contacted.md" %} + + +!!! tip "Quality Contact Method" + + A quality contact method is a publicly posted known good email address, public portal on vendor website, etc. + + diff --git a/docs/reference/decision_points/supplier_engagement.md b/docs/reference/decision_points/supplier_engagement.md new file mode 100644 index 00000000..42e306af --- /dev/null +++ b/docs/reference/decision_points/supplier_engagement.md @@ -0,0 +1,3 @@ +# Supplier Engagement + +{% include-markdown "../../_generated/decision_points/supplier_engagement.md" %} diff --git a/docs/reference/decision_points/supplier_involvement.md b/docs/reference/decision_points/supplier_involvement.md new file mode 100644 index 00000000..d28e978e --- /dev/null +++ b/docs/reference/decision_points/supplier_involvement.md @@ -0,0 +1,3 @@ +# Supplier Involvement + +{% include-markdown "../../_generated/decision_points/supplier_involvement.md" %} diff --git a/docs/reference/decision_points/system_exposure.md b/docs/reference/decision_points/system_exposure.md new file mode 100644 index 00000000..9ada4318 --- /dev/null +++ b/docs/reference/decision_points/system_exposure.md @@ -0,0 +1,41 @@ +# System Exposure + +{% include-markdown "../../_generated/decision_points/system_exposure.md" %} + +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. + + +## 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](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* 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*](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_](../../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). + +## Prior Versions + +{% include-markdown "../../_generated/decision_points/system_exposure_1_0_0.md" %} diff --git a/docs/reference/decision_points/technical_impact.md b/docs/reference/decision_points/technical_impact.md new file mode 100644 index 00000000..f7280b9a --- /dev/null +++ b/docs/reference/decision_points/technical_impact.md @@ -0,0 +1,31 @@ +# Technical Impact + +{% include-markdown "../../_generated/decision_points/technical_impact.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. + +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. + + +!!! tip "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](https://github.com/CERTCC/SSVC/issues). + diff --git a/docs/reference/decision_points/utility.md b/docs/reference/decision_points/utility.md new file mode 100644 index 00000000..93e94124 --- /dev/null +++ b/docs/reference/decision_points/utility.md @@ -0,0 +1,52 @@ +# Utility + +{% include-markdown "../../_generated/decision_points/utility.md" %} + +!!! tip "See also" + + Utility is a combination of [Automatable](./automatable.md) and + [Value Density](./value_density.md) + + +This is a compound decision point, therefore it is a notational convenience. + +*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*](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. + +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. +[*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 above. + + +## 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](https://zerodium.com/program.html), make such pricing structures public. +The valuable exploits track the [*Automatable*](automatable.md) and [*Value Density*](value_density.md) 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*](automatable.md) exploits for different systems are priced relative to each other is more idiosyncratic. +Price does not only track the [*Value Density*](value_density.md) 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. + + + +## Previous Versions + +{% include-markdown "../../_generated/decision_points/utility_1_0_0.md" %} + +!!! tip "See also" + + Utility v1.0.0 was a combination of [Virulence](./automatable.md) and + [Value Density](./value_density.md) \ No newline at end of file diff --git a/docs/reference/decision_points/value_density.md b/docs/reference/decision_points/value_density.md new file mode 100644 index 00000000..934231f6 --- /dev/null +++ b/docs/reference/decision_points/value_density.md @@ -0,0 +1,46 @@ +# Value Density + +{% include-markdown "../../_generated/decision_points/value_density.md" %} + +!!! tip "See also" + + Value Density combines with [Automatability](./automatable.md) to inform + [Utility](./utility.md). + +!!! 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.md), 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* 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. diff --git a/docs/reference/index.md b/docs/reference/index.md new file mode 100644 index 00000000..af7ff33b --- /dev/null +++ b/docs/reference/index.md @@ -0,0 +1,29 @@ +# SSVC Reference + +!!! tip inline end "Prerequisites" + + 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/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/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: + + +
+ +- :material-arrow-decision-outline: [**Decision Points**](decision_points/index.md) + + --- + + A list of all the decision points, values, and versions. + +- :material-language-python: [**Code Documentation**](code/index.md) + + --- + + Documentation for the SSVC 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 97% rename from ssvc-calc/Deployer.json rename to docs/ssvc-calc/Deployer.json index bf749350..fb4af309 100644 --- a/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/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 98% rename from ssvc-calc/css.css rename to docs/ssvc-calc/css.css index 2a72c66d..ecf4f301 100644 --- a/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; @@ -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/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/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/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/ssvc-calc/main.css b/docs/ssvc-calc/main.css similarity index 100% rename from ssvc-calc/main.css rename to docs/ssvc-calc/main.css diff --git a/ssvc-calc/moon_icon.png b/docs/ssvc-calc/moon_icon.png similarity index 100% rename from ssvc-calc/moon_icon.png rename to docs/ssvc-calc/moon_icon.png diff --git a/ssvc-calc/index.html b/docs/ssvc-calc/old_index.html similarity index 99% rename from ssvc-calc/index.html rename to docs/ssvc-calc/old_index.html index bdfc662b..32b1e3d6 100644 --- a/ssvc-calc/index.html +++ b/docs/ssvc-calc/old_index.html @@ -34,7 +34,7 @@ CERT Logo + onclick="$('body').toggleClass('blackbody').toggleClass('whitebody')"/>
@@ -57,7 +57,7 @@

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