diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 0000000..5d38038 --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,13 @@ +# These rules follow a last-match behavior. + +# default (if nothing else matches) +* @ahouseholder @ehatleback + +# any markdown file in docs +/docs/**/*.md @ahouseholder @ehatleback + +# 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 0000000..1337cb6 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,41 @@ +--- +name: Bug report +about: Create a report to help us improve +title: '' +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. + +**Desktop (please complete the following information):** + +- OS: [e.g. iOS] +- Browser [e.g. chrome, safari] +- Version [e.g. 22] + +**Smartphone (please complete the following information):** + +- Device: [e.g. iPhone6] +- OS: [e.g. iOS8.1] +- Browser [e.g. stock browser, safari] +- Version [e.g. 22] + +**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 index bbcbbe7..11fc491 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -2,7 +2,7 @@ name: Feature request about: Suggest an idea for this project title: '' -labels: '' +labels: enhancement assignees: '' --- diff --git a/.github/ISSUE_TEMPLATE/question.md b/.github/ISSUE_TEMPLATE/question.md new file mode 100644 index 0000000..3aba565 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/question.md @@ -0,0 +1,13 @@ +--- +name: Question +about: Ask the CERT Guide to CVD team a question +title: Add a concise title for your question +labels: question +assignees: '' + +--- + +*Note:* Questions for the CERT Guide to CVD team can be asked here in the form of an issue. +More general questions directed at the CERT Guide to CVD user community +might be a better fit in the [Q&A](https://github.com/CERTCC/CERT-Guide-to-CVD/discussions/categories/q-a) category of our +[Discussions](https://github.com/CERTCC/CERT-Guide-to-CVD/discussions) area. diff --git a/.github/dependabot.yml b/.github/dependabot.yml new file mode 100644 index 0000000..1114502 --- /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/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000..24c6215 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1 @@ +*Contributions to this project are subject to the terms listed in [CONTRIBUTING.md](CONTRIBUTING.md).* diff --git a/.github/workflows/deploy_site.yml b/.github/workflows/deploy_site.yml new file mode 100644 index 0000000..a1d14f6 --- /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 the default branch + 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.11' + + - name: Install dependencies + run: | + python -m pip install --upgrade pip + python -m pip install -r requirements.txt + + - name: Setup Pages + uses: actions/configure-pages@v5 + + - 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/linkchecker.yml b/.github/workflows/linkchecker.yml new file mode 100644 index 0000000..7f96049 --- /dev/null +++ b/.github/workflows/linkchecker.yml @@ -0,0 +1,34 @@ +name: Link Checker +on: + pull_request: + paths: + - '**/*.md' + - .github/workflows/linkchecker.yml + 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 +# python -m pip install -e . + + - 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/lint_md_all.yml b/.github/workflows/lint_md_all.yml new file mode 100644 index 0000000..2c1d5b6 --- /dev/null +++ b/.github/workflows/lint_md_all.yml @@ -0,0 +1,15 @@ +name: "Lint Markdown (all)" + +on: + workflow_dispatch: + +jobs: + lint: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - uses: DavidAnson/markdownlint-cli2-action@v16 + with: + globs: | + *.md + !test/*.md diff --git a/.github/workflows/lint_md_changes.yml b/.github/workflows/lint_md_changes.yml new file mode 100644 index 0000000..c63eb02 --- /dev/null +++ b/.github/workflows/lint_md_changes.yml @@ -0,0 +1,26 @@ +name: "Lint Markdown (Changes)" +on: + pull_request: + paths: + - '**/*.md' + - .github/workflows/lint_md_changes.yml + +jobs: + lint: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + with: + fetch-depth: 0 + - uses: tj-actions/changed-files@v44 + id: changed-files + with: + files: '**/*.md' + separator: "," + - uses: DavidAnson/markdownlint-cli2-action@v16 + if: steps.changed-files.outputs.any_changed == 'true' + with: + globs: ${{ steps.changed-files.outputs.all_changed_files }} + separator: "," + config: .markdownlint-cli2.yaml + diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..1fb9ef5 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +tmp/* diff --git a/.markdownlint-cli2.yaml b/.markdownlint-cli2.yaml new file mode 100644 index 0000000..1e654f7 --- /dev/null +++ b/.markdownlint-cli2.yaml @@ -0,0 +1,29 @@ +config: + # 0004 Unordered List style + # Force dash style for unordered lists + "MDOO4": + style: "dash" + # 013 Line length + # Disabled because we have a lot of long lines. We should fix this eventually. + "MD013": false + # 033 Inline HTML + # Disabled because we use inline HTML (
in table cells for example) + "MD033": false + # 041 First line in file should be a top level header + # Disabled because we use `include-markdown` plugin for merging markdown files + "MD041": false + # 046 Code block style + # Disabled because mkdocs-material uses indented blocks for admonitions + "MD046": false + # 049 emphasis style + # Force asterisk style for emphasis + "MD049": + style: "asterisk" + # 050 strong style + # Force asterisk style for strong + "MD050": + style: "asterisk" + # 051 Link fragments should be valid + # Disabled because conversion from TeX to markdown produces invalid links + # We might eventually be able to re-enable this one. + "MD051": false diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..2dab788 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,109 @@ +# Contributing to the CERT Guide to CVD + +Thank you for your interest in contributing to the +**CERT Guide to Coordinated Vulnerability Disclosure** +project (“We” or “Us”). +By making any Contribution to this project, you agree to the terms outlined below. + +**IF YOU DO NOT AGREE TO THESE TERMS, DO NOT SUBMIT ANY CONTRIBUTION TO THIS PROJECT.** + +## TERMS OF SUBMISSION (“Agreement”) + +### 1. Definitions + +- "**You**" means the individual who Submits a Contribution to Us. +- "**Contribution**" means any work of authorship, including but not limited to source code, object code, patch, tool, + sample, graph, specification, manual documentation, that is Submitted by You to Us in which You own or assert + ownership of the Copyright. +- "**Copyright**" means all rights protecting works of authorship owned or controlled by You, including copyright, moral + and neighboring rights, as appropriate, for the full term of their existence including any extensions by You. +- "**Material**" means the work of authorship which is made available by Us to third parties. When this Agreement covers + more than one software project, the Material means the work of authorship to which the Contribution was Submitted. + After You Submit the Contribution, it may be included in the Material. +- "**Submit**" means any form of electronic, verbal, or written communication sent to Us or our representatives, including + but not limited to electronic mailing lists, source code control systems, and issue tracking systems that are managed + by, or on behalf of, Us for the purpose of discussing and improving the Material, but excluding communication that is + conspicuously marked or otherwise designated in writing by You as "Not a Contribution." +- "**Submission Date**" means the date on which You Submit a Contribution to Us. +- "**Effective Date**" means the date You first Submit a Contribution to Us, whichever is earlier. +- "**Media**" means any portion of a Contribution which is not software. + +### 2. Grant of Rights + +#### 2.1 Copyright License + +**(a)** You retain ownership of the Copyright in Your Contribution and have the same rights to use or license the +Contribution which You would have had without entering into the Agreement. + +**(b)** To the maximum extent permitted by the relevant law, You grant to Us a perpetual, worldwide, non-exclusive, +transferable, royalty-free, irrevocable license, with the right to sublicense such rights through multiple tiers of +sublicensees, to reproduce, modify, display, perform and distribute the Contribution as part of the Material; +provided that this license is conditioned upon compliance with Section 2.2. + +#### 2.2 Outbound License + +Based on the grant of rights in Section 2.1, if We include Your Contribution in a Material, +We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. +As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license +or licenses which We are using for the Material on the Submission Date. + +#### 2.3 Moral Rights + +If moral rights apply to the Contribution, to the maximum extent permitted by law, You waive and agree not to assert +such moral rights against Us or our successors in interest, or any of our licensees, either direct or indirect. + +#### 2.4 Our Rights + +You acknowledge that We are not obligated to use Your Contribution as part of the Material and may decide to include any +Contribution We consider appropriate. + +#### 2.5 Reservation of Rights + +Any rights not expressly assigned or licensed under this section are expressly reserved by You. + +### 3. General Terms + +**3.1** You warrant that: + +**(a)** You have the legal authority to enter into this Agreement. + +**(b)** You own all rights, including but not limited to Copyright, covering the Contribution which are required to grant +the rights under Section 2. To the extent the Contribution incorporates text passages, figures, data or other +material from the works of others, You warrant that you have obtained any necessary permissions to make this +Contribution. + +**(c)** The grant of rights under Section 2 does not violate any grant of rights which You have made to third parties, +including Your employer. If You are an employee, You warrant that Your employer has approved this Agreement. If You +are less than eighteen years old, Your parent or guardian must sign a printed version of this Agreement and send it +to . + +**(d)** You shall make each Contribution in full compliance with U.S. export control laws. + +**3.2** You agree to notify Us if You become aware of any circumstance that would make any of the foregoing warranties inaccurate in any respect. + +**3.3** You agree to indemnify and hold Us harmless from any damage or expense that may arise in the event of a breach of +any of the warranties set forth above. + +**3.4** You agree that We may publicly disclose your participation in this project and the fact that you agreed to the terms +of this Agreement. + +### 4. Miscellaneous + +**4.1** This Agreement will be governed by and construed in accordance with the laws of Pennsylvania excluding its +conflicts of law provisions. + +**4.2** This Agreement sets out the entire agreement between You and Us for Your Contributions to Us and overrides all +other agreements or understandings. + +**4.3** If You or We assign the rights or obligations received through this Agreement to a third party, as a condition of the assignment, that third party must agree in writing to abide by all the rights and obligations in the Agreement. + +**4.4** The failure of either party to require performance by the other party of any provision of this Agreement in one +situation shall not affect the right of a party to require such performance at any time in the future. A waiver of +performance under a provision in one situation shall not be considered a waiver of the performance of the provision +in the future or a waiver of the provision in its entirety. + +**4.5** If any provision of this Agreement is found by a court of competent jurisdiction to be void and unenforceable, +such provision will be replaced to the extent possible with a provision that comes closest to the meaning of the +original provision and which is enforceable. The terms and conditions set forth in this Agreement shall apply +notwithstanding any failure of essential purpose of this Agreement or any limited remedy to the maximum extent +possible under law. diff --git a/COPYRIGHT.md b/COPYRIGHT.md new file mode 100644 index 0000000..3522be2 --- /dev/null +++ b/COPYRIGHT.md @@ -0,0 +1,44 @@ +# Copyright + +Copyright® 2017-2024 Carnegie Mellon University. All Rights Reserved. + +This material is based upon work funded and supported by the Department +of Defense under Contract No. FA8702-15-D-0002 with Carnegie Mellon +University for the operation of the Software Engineer- ing Institute, a +federally funded research and development center. + +The view, opinions, and/or findings contained in this material are those +of the author(s) and should not be construed as an official Government +position, policy, or decision, unless designated by other documentation. + +This report was prepared for the SEI Administrative Agent AFLCMC/AZS 5 +Eglin Street Hanscom AFB, MA 01731-2100 + +NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING +INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON +UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, +AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR +PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF +THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF +ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT +INFRINGEMENT. + +[DISTRIBUTION STATEMENT A] This material has been approved for public +release and unlimited distribution. Please see Copyright notice for +non-US Government use and distribution. + +Internal use:[^1] Permission to reproduce this material and to prepare +derivative works from this material for internal use is granted, +provided the copyright and "No Warranty" statements are included with +all reproductions and derivative works. + +External use:[^1] This material may be reproduced in its entirety, without +modification, and freely distributed in written or electronic form +without requesting formal permission. Permission is required for any +other external and/or commercial use. Requests for permission should be +directed to the Software Engineering Institute at +[permission@sei.cmu.edu](mailto:permission@sei.cmu.edu). + +[^1]: These restrictions do not apply to U.S. government entities. + +DM17-0508 diff --git a/README.md b/README.md index d044c61..877de69 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,16 @@ # CERT® Guide to Coordinated Vulnerability Disclosure -This repository is intended for use as an issues-only tracker to collect suggested changes to the [CERT Guide to Coordinated Vulnerability Disclosure](https://vuls.cert.org/confluence/display/CVD) from the community. -The original 2017 version of the Guide is available as a PDF in the [SEI Resource Library](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=503330). The most up-to-date version is available as a web site: [CERT Guide to Coordinated Vulnerability Disclosure](https://vuls.cert.org/confluence/display/CVD) +This repository contains the full content of the +[CERT Guide to Coordinated Vulnerability Disclosure](https://certcc.github.io/CERT-Guide-to-CVD) +as a collection of markdown files. -If you have a suggestion for a change, clarification, or addition to the Guide, please [submit an issue](https://github.com/CERTCC/CERT-Guide-to-CVD/issues). +We welcome contributions to the Guide. +Please see the [CONTRIBUTING.md](CONTRIBUTING.md) file for more information. + +The original 2017 version of the Guide is available as a PDF in the +[SEI Resource Library](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=503330). +The most up-to-date version is available as a web site: +[CERT Guide to Coordinated Vulnerability Disclosure](https://certcc.github.io/CERT-Guide-to-CVD) + +If you have a suggestion for a change, clarification, or addition to the +Guide, please [submit an issue](https://github.com/CERTCC/CERT-Guide-to-CVD/issues). diff --git a/docs/_drafts/community_management.md b/docs/_drafts/community_management.md new file mode 100644 index 0000000..4151046 --- /dev/null +++ b/docs/_drafts/community_management.md @@ -0,0 +1,94 @@ +# Community Management + +Remediating system vulnerabilities requires groups of people to work together to achieve a common goal. +From the initial discovery of a vulnerability to the final deployment of a patch, many different stakeholders are involved in the process. +Organizations that serve as Coordinators of the vulnerability disclosure process must manage relationships with these stakeholders to ensure that the process is successful. +Often, these organizations must also manage relationships with other organizations that are not directly involved in the vulnerability disclosure process but are affected by it. +We refer to these groups of people as "communities of interest." + +!!! tip "*Community Management* is closely related to *Policy Management*" + + [_Policy Management_](./policy_management.md) is about defining the rules and guidelines that govern the + vulnerability disclosure process + for a particular organization or community. + Disclosure policies define the scope of the organization's interest in vulnerability reports, the exceptions + to the policy, and the safe harbor provisions for reporters. + They can also include requirements for who will be engaged during the disclosure process and how they will be engaged. + + In contrast, _Community Management_ is about the relationships that an organization must maintain with the people and + organizations involved in the vulnerability disclosure process over time. + This includes maintaining relationships with the people who report vulnerabilities, the vendors who must fix them, and the deployers who must install the fixes. + + One might think of _Policy Management_ as defining the rules of the game, while _Community Management_ is about + developing and maintaining a pool of players who are willing to play by those rules. + +## Communities of Interest + +We can categorize the communities of interest in the vulnerability disclosure process in several ways. + +### By Role + +One way is to categorize them by their role in the process. + +#### Finder/Reporter Communities + + + + + +#### Vendor/Developer Communities + + + +#### Deployer/Operator Communities + + + +#### Coordinator Communities + + + +### By Technology Affinity + +Another way to categorize communities of interest is by the technology type affected by the vulnerability. +Often used by Coordinators + + + +### By Industry Affinity + + + +### By Geography or Jurisdiction + + + + diff --git a/docs/_drafts/laws_and_regs.md b/docs/_drafts/laws_and_regs.md new file mode 100644 index 0000000..3ecbb70 --- /dev/null +++ b/docs/_drafts/laws_and_regs.md @@ -0,0 +1,163 @@ +# Legal and Regulatory Issues + +## DMCA and CFAA + +Things we might include: DVD decryption code. + +John Deere and the right-to-repair controversy. + +"Safe harbor" might not mean what you think it means. Organizations +might choose not to prosecute, but that does not mean you are protected +from criminal prosecution by law enforcement. + +Pointer to EFF stuff. + +## Wassenaar Arrangement + +"Zero Day exploit capability" as a meaningless term. Current status\... + +## 2020 BOD + +## 2021 Cybersecurity EO + +## something about EU? + +GDPR and CVD? + +Do we know anything about EU CVD status? + +## Canada + +## International Trade Sanctions and CVD + +Individuals and organizations conducting CVD on a global scale might encounter a +challenge at the intersection of CVD and international trade sanctions imposed +by their home government. Here we present an anecdote from our own +experience at the [CERT/CC]{acronym-label="CERT/CC" +acronym-form="singular+short"} (in the United States), highlighting how +we approached and worked through a related issue a few years ago. Our +experiences here are provided as examples only, none of what follows +should be taken as legal advice. We include this with the observation +that organizations in other countries may be subject to similar +requirements imposed by their respective governments. + +The OFAC within the +U.S. Department of the Treasury administers and enforces economic and +trade sanctions based on U.S. foreign policy and national security +goals.[@0] + +> U.S. persons must comply with OFAC regulations, including all U.S. +> citizens and permanent resident aliens regardless of where they are +> located, all persons and entities within the United States, all U.S. +> incorporated entities and their foreign branches. In the cases of +> certain programs, foreign subsidiaries owned or controlled by U.S. +> companies also must comply. Certain programs also require foreign +> persons in possession of U.S.-origin goods to comply. + +As a vendor, reporter, or coordinator in the U.S., should you become +aware that an individual or organization participating in a +CVD case is named +on OFAC's +SDN[^1], you need +to decide whether you are willing to continue coordinating with the +sanctioned party. You may already know that your reporter or the +organization is on an OFAC list. If they know, they'll often tell +you. + +U.S.-based organizations participating in CVD internationally may need +to engage their legal counsel to request a review of the sanctions list. +~~Take care when using the sanctions list search application, as common +names may result in a false-positive result.~~ + +Should it be necessary, CVD participants can work with their legal +counsel and the CISA to obtain a license from +OFAC[^2]. ~~The +[CERT/CC]{acronym-label="CERT/CC" acronym-form="singular+short"} has on +two occasions contacted CISA for support in obtaining an +OFAC license.~~ +Inform the SDN that +you are in the process of obtaining an OFAC license and ask for their patience and +understanding. Maintain your flexibility, as the approval and issuance +of a License can take 30 to 60 days. + +~~For this discussion, the reporter or organization associated with the +reporter is on the sanctioned list.~~ + +Once you have been granted a Cyber-Related Sanctions Regulations License +you must follow the requirements. The CERT/CC has been party to two +licenses. These licenses had four sections: + +1. A description of the authorization. In our case, it stated that the + License was being issued to CISA and listed the other parties, known + as *Licensees*, which have been authorized to engage with the + SDN "for the + purpose of addressing certain software vulnerabilities that threaten + U.S. companies, as described in the Application." + +2. A set of limitations on the license. In our case, the license + indicated that the SDN is subject to the "blocked property" + requirement: there can be no transaction of property. + +3. Record keeping and reporting requirements. The + [CERT/CC]{acronym-label="CERT/CC" acronym-form="singular+short"} met + this requirement by maintaining copies of email records and database + entries separately to facilitate timely reporting. The + OFAC License + required a report every 90 days as well as a detailed final report + no later than 30 days following the expiration of the License. As + the time, all reports needed to be physically mailed to the + Department of the Treasury. + +4. A description of license dependencies, including the expiration date + for the License. + +~~Section 4 states the "License is limited to the facts and +circumstances specified in the Application."~~ If you are working +directly with CISA, you will need to create a compliance +plan. Where possible, limit the number of your personnel impacted by the +compliance plan. Request participation from your legal department for +creation and implementation of the compliance plan. Your compliance plan +will state who is involved, that they agreed to abide by the blocked +property restriction, and the frequency of which you will be reporting +contact with the SDN. The [CERT/CC]{acronym-label="CERT/CC" +acronym-form="singular+short"} Compliance Plan consisted of two pages. +Personnel involved in the coordination efforts will be asked to sign an +Individual Compliance Certification, indicating they have read and +understand the requirements of the License and agree to comply. + +~~Conduct the coordination effort with special attention to the meeting +your CVD goals and +recording all correspondence with the SDN.~~ A potential for breaking the license +agreement comes with bug bounty programs. ~~Remember, the +OFAC License +strictly enforces the "blocked property" requirement, and does not allow +for material transactions or rewards.~~ ~~Maintain your recordkeeping +and submit timely reports.~~ ~~Continue to submit timely reports whether +or not there is any new correspondence.~~ ~~In these cases, the report +can simply state "no communications have occurred since the last +report."~~ ~~Submit your final report and you're done!~~ + +## China Data Security Law 2021 + +Section 7.1 requires network product providers to verify and assess the +risk of reported vulnerabilities, reporting to upstream vendors as +necessary. Section 7.2 mandates reporting to the Ministry of Industry +and Information Technology's cyber security threat and vulnerability +information sharing program within 2 days + +> The DSL's provisions require all Chinese security researchers, Chinese +> businesses, and — most notably — foreign companies with a +> footprint inside China to report any zero-day vulnerability to the +> Chinese Ministry of Industry and Information Technology (MIIT) within +> two days of a vulnerability's discovery. The DSL also prohibits +> affected entities from "collect\[ing\], sell\[ing\], or publish\[ing\] +> information on network product security vulnerabilities" and outlaws +> sharing vulnerabilities with any "overseas organizations or +> individuals other than network product providers." + +from [@0] + +[^1]: + +[^2]: A license is an authorization from OFAC to engage in a transaction that + otherwise would be prohibited. diff --git a/docs/_drafts/platform_interoperability.md b/docs/_drafts/platform_interoperability.md new file mode 100644 index 0000000..da7b5c2 --- /dev/null +++ b/docs/_drafts/platform_interoperability.md @@ -0,0 +1,17 @@ +# CVD Platform Interoperability + + diff --git a/docs/_drafts/policy_management.md b/docs/_drafts/policy_management.md new file mode 100644 index 0000000..4fe5b29 --- /dev/null +++ b/docs/_drafts/policy_management.md @@ -0,0 +1,171 @@ +# Policy Management + +Policy management for CVD consists of two areas of focus: external +and internal policy. External policy includes choosing disclosure and +embargo policies. Internal policy needs to address how vulnerability +reports are shared within the organization. We cover each of these +below. + +
+ +- Disclosure Policy +- Embargo Policy +- Internal Case Handling Policy + +
+ +## Disclosure Policy + +For those responsible for implementing the CVD process, defining a +disclosure policy is an important first step. A well-defined policy +makes it clear what other participants in the CVD process can expect +when they engage with you and establishes good relationships between +finders, reporters, vendors, coordinators, and other stakeholders. + +A disclosure policy typically describes what CVD stakeholders (finders, +reporters, vendors, coordinators) can expect in terms of these factors: + +Scope + +: A description of the scope of issues to which the policy applies. + This scope should be as explicit as possible, especially when there + are specific boundaries of concern to the organization. If a bounty + is to be paid for some classes of vulnerability reports, the scope + definition should clearly delineate which kinds of reports will be + eligible for the bounty. See + {== §[\[sec:cvd_scope\]](#sec:cvd_scope){reference-type="ref" + reference="sec:cvd_scope"} ==} for how scope is applied to report + intake. + +Exceptions + +: Any exceptional conditions that may alter the typical flow of the + process. Common examples include evidence of attacks + ({== §[\[sec:tr_exploit_public\]](#sec:tr_exploit_public){reference-type="ref" + reference="sec:tr_exploit_public"} ==}) or vulnerabilities with safety + or critical infrastructure impact + ({== §[\[sec:tr_ci_impact\]](#sec:tr_ci_impact){reference-type="ref" + reference="sec:tr_ci_impact"} ==}). + +Safe Harbor + +: Should your organization choose to explicitly disavow legal + retribution against reporters who otherwise follow the policy, that + fact should be clearly laid out in the policy document. + +Report quality requirements + +: It's okay to require reports to meet a certain level of quality + before committing to taking action on them. See + {== §[\[sec:validating_reports\]](#sec:validating_reports){reference-type="ref" + reference="sec:validating_reports"} ==} for more on report quality + assessment. However, it's also useful to judiciously apply the + principle of robustness here: "In general, an implementation should + be conservative in its sending behavior, and liberal in its + receiving behavior" [@rfc760]. + +Preferred Communication Language(s) + +: If the organization has preferences for specific (human) languages + for reports, the policy should specify this. That said, English is + usually acceptable as a default. + +Contact Information + +: How should reports be submitted? How can you be reached? See + {== §[\[sec:reporting_for_vendors\]](#sec:reporting_for_vendors){reference-type="ref" + reference="sec:reporting_for_vendors"} ==} for advice to vendors on + improving the reporting experience for reporters. + +Timing + +: Setting expectations for response timelines of the various + milestones in a vulnerability report case can be helpful too. Most + important are expected time to acknowledge receipt of a report and a + default disclosure timeframe if one has been defined. An + acknowledgement timeframe of 24-48 hours is common for vendors and + coordinators, while 45-90 days seems to be the normal range for + disclosures these days. That said, we recommend that both vendors + and reporters treat policy-declared disclosure timeframes as the + starting point of a negotiation process rather than a hard deadline. + +A few examples of vulnerability disclosure policies can be found in +Appendix +[\[apx:policy_templates\]](#apx:policy_templates){reference-type="ref" +reference="apx:policy_templates"}. + +RFC 2350 provides recommendations on how to publish information about +your CSIRT and disclosure policy and procedures [@rfc2350]. + +### Embargo policy + +#### Embargo entry criteria + +Fix not deployed. Not public. No exploits public. No attacks observed. +($fpxa$) + +#### Embargo exit criteria + +Timer expired. Exploit public ($pX$). Attacks observed ($pA$). Fix ready +($Vfdp \xrightarrow{F} VFdp$) Fix deployed ($VFDp \xrightarrow{D} VFDp$) +etc. + + + +### Coordinating Further Downstream + +Vulnerabilities having the potential for significant impact can lead to +coordination efforts beyond the traditional product vendor space. +Infrastructure and service providers are sometimes brought in early, if +there are mitigations that can be deployed in advance of the +availability of a fix. This can be especially helpful in cases where the +vulnerability may affect the infrastructure necessary to distribute the +patch in the first place. + +### Do You Include Deployers? + +Be careful to consider fairness though: By what criteria should you +notify service provider X but not service provider Y? At some point, the +complexity of who knows what gets high enough that the likelihood of a +leak goes to 1, and you might as well go public. + +### Do You Include Governments? + + + +## Internal case handling policy + + \ No newline at end of file diff --git a/docs/_includes/_NIST_SP_800-40.md b/docs/_includes/_NIST_SP_800-40.md new file mode 100644 index 0000000..9006baf --- /dev/null +++ b/docs/_includes/_NIST_SP_800-40.md @@ -0,0 +1,37 @@ +!!! info "NIST SP 800-40" + + [NIST SP 800-40 Rev. 4 _Guide to Enterprise Patch Management Planning_](https://csrc.nist.gov/pubs/sp/800/40/r4/final) + frames patch management as preventative maintenance for information systems. + Skimming the section headings of NIST SP 800-40 provides a good overview of the process and + objectives of VM practices: + +
+ + - **Risk Response Approaches for Software Vulnerabilities** + + --- + - Risk Responses + - Software Vulnerability Management Life Cycle + - Risk Response Execution + + - Prepare to Deploy the Patch + - Deploy the Patch + - Verify Deployment + - Monitor the Deployed Patches + + - **Recommendations for Enterprise Patch Management Planning** + + --- + - Reduce Patching-Related Disruptions + - Inventory Your Software and Assets + - Define Risk Response Scenarios + - Assign Each Asset to a Maintenance Group + - Define Maintenance Plans for Each Maintenance Group + - Routine Patching + - Emergency Patching + - Emergency Mitigation + - Unpatchable Assets + - Exceptions to Maintenance Plans + - Choose Actionable Enterprise-Level Patching Metrics + - Consider Software Maintenance in Procurement +
diff --git a/docs/_includes/_acronyms.md b/docs/_includes/_acronyms.md new file mode 100644 index 0000000..803646a --- /dev/null +++ b/docs/_includes/_acronyms.md @@ -0,0 +1,181 @@ + +*[ACM]: Association for Computing Machinery +*[AFB]: Air Force Base +*[AFLCMC]: Air Force Life Cycle Management Center +*[AI]: Artificial Intelligence +*[AMA]: Ask Me Anything +*[API]: Application Programming Interface +*[ASCII]: American Standard Code for Information Interchange +*[ATMs]: Automated Teller Machines +*[ATM]: Automated Teller Machine + +*[BCP]: Best Current Practice +*[BFF]: CERT Basic Fuzzing Framework +*[BGP]: Border Gateway Protocol +*[BIND]: Berkeley Internet Name Domain +*[BOD]: Binding Operational Directive + +*[CAPEC]: Common Attack Pattern Enumeration and Classification +*[CA]: Certificate Authority +*[CERT/CC]: CERT Coordination Center, a part of the Software Engineering Institute at Carnegie Mellon University +*[CERT]: The CERT Division of the Software Engineering Institute +*[CISA]: Cybersecurity and Infrastructure Security Agency, a part of the U.S. Department of Homeland Security +*[CI]: Continuous Integration +*[CD]: Continuous Deployment +*[CMU]: Carnegie Mellon University +*[CNAs]: CVE Numbering Authorities +*[CNA]: CVE Numbering Authority +*[COPPA]: Children's Online Privacy Protection Act +*[CPE]: Common Platform Enumeration +*[CSAF]: Common Security Advisory Framework +*[CSIRTs]: Computer Security Incident Response Teams +*[CSIRT]: Computer Security Incident Response Team +*[MPCVD]: Multi-Party Coordinated Vulnerability Disclosure +*[CVD]: Coordinated Vulnerability Disclosure +*[CVE]: Common Vulnerabilities and Exposures +*[CVRF]: Common Vulnerability Reporting Format, superseded by the Common Security Advisory Framework (CSAF) +*[CVSS]: Common Vulnerability Scoring System +*[CWE]: Common Weakness Enumeration +*[CWSS]: Common Weakness Scoring System + +*[DFIR]: Digital Forensics and Incident Response +*[DHS]: U.S. Department of Homeland Security +*[DNS]: Domain Name System +*[DoD]: U.S. Department of Defense +*[DoJ]: U.S. Department of Justice +*[DDoS]: Distributed Denial of Service +*[DoS]: Denial of Service + +*[EFF]: Electronic Frontier Foundation +*[ENISA]: European Union Agency for Cybersecurity +*[EOL]: End of Life +*[EO]: Executive Order +*[EU]: European Union + +*[FAQ]: Frequently Asked Questions +*[FCC]: U.S. Federal Communications Commission +*[FBI]: U.S. Federal Bureau of Investigation +*[FDA]: U.S. Food and Drug Administration +*[FERPA]: Family Educational Rights and Privacy Act +*[FIRST]: Forum of Incident Response and Security Teams +*[FI]: Finland +*[FTC]: U.S. Federal Trade Commission +*[FTP]: File Transfer Protocol + +*[GnuPG]: GNU Privacy Guard, an implementation of the OpenPGP standard +*[GPG]: GNU Privacy Guard, an implementation of the OpenPGP standard + +*[HIPPA]: Health Insurance Portability and Accountability Act +*[HTML]: Hyper Text Markup Language +*[HTTP]: Hyper Text Transfer Protocol +*[HTTPS]: Hyper Text Transfer Protocol Secure +*[HVAC]: Heating, Ventilation, and Air Conditioning + +*[IEC]: International Electrotechnical Commission +*[IEEE]: Institute of Electrical and Electronics Engineers +*[IETF]: Internet Engineering Task Force +*[IoT]: Internet of Things +*[IP]: Internet Protocol +*[ISACs]: Information Sharing and Analysis Centers +*[ISAC]: Information Sharing and Analysis Center +*[ISAOs]: Information Sharing and Analysis Organizations +*[ISAO]: Information Sharing and Analysis Organization +*[ISO]: International Organization for Standardization +*[ISPs]: Internet Service Providers +*[ISP]: Internet Service Provider + +*[JPCERT/CC]: Japan Computer Emergency Response Team Coordination Center +*[JSON]: JavaScript Object Notation +*[JTAG]: Joint Test Action Group +*[JVN]: Japan Vulnerability Notes + +*[ML]: Machine Learning +*[MON]: The Monitoring Process Area of the CERT Resilience Management Model +*[MPLS]: Multiprotocol Label Switching + +*[NCSC]: National Cyber Security Centre +*[NDAs]: Non-Disclosure Agreements +*[NDA]: Non-Disclosure Agreement +*[NHTSA]: National Highway Traffic Safety Administration +*[NIAC]: National Infrastructure Advisory Council +*[NIST]: National Institute of Standards and Technology +*[NL]: The Netherlands +*[NTIA]: National Telecommunications and Information Administration +*[NTP]: Network Time Protocol +*[NVD]: National Vulnerability Database + +*[OASIS]: Organization for the Advancement of Structured Information Standards +*[OCTAVE]: Operationally Critical Threat, Asset, and Vulnerability Evaluation +*[OpSec]: Operational Security +*[OS]: Operating System +*[OUSPG]: Oulu University Secure Programming Group + +*[PCI DSS]: Payment Card Industry Data Security Standard +*[PGP]: Pretty Good Privacy +*[PoC]: Proof of Concept Exploit +*[PSIRTs]: Product Security Incident Response Teams +*[PSIRT]: Product Security Incident Response Team + +*[REST]: Representational State Transfer +*[RE]: Reverse Engineering +*[RFCs]: Requests for Comments +*[RFC]: Request for Comments +*[RFID]: Radio Frequency Identification +*[RMM]: The CERT Resilience Management Model + +*[SAAS]: Software as a Service +*[SaaS]: Software as a Service +*[SBOM]: Software Bill of Materials +*[SCAP]: Security Content Automation Protocol +*[SDLC]: Secure Development Lifecycle +*[SDL]: Software Development Lifecycle +*[SDR]: Software Defined Radio +*[SEC]: U.S. Securities and Exchange Commission +*[SEI]: Software Engineering Institute +*[SERA]: Security Engineering Risk Analysis +*[SIG]: Special Interest Group +*[SME]: Subject Matter Expert +*[SMTP]: Simple Mail Transfer Protocol +*[SNMP]: Simple Network Management Protocol +*[SPDX]: Software Package Data Exchange +*[SP]: Special Publication +*[SR]: Special Report +*[SSL]: Secure Sockets Layer +*[SSVC]: Stakeholder-Specific Vulnerability Categorization +*[STARTTLS]: Start Transport Layer Security, a protocol extension for upgrading a plaintext connection to a secure connection +*[StartTLS]: Start Transport Layer Security, a protocol extension for upgrading a plaintext connection to a secure connection + +*[TCP]: Transmission Control Protocol +*[TLP]: Traffic Light Protocol +*[TTPs]: Tactics, Techniques, and Procedures +*[TTP]: Tactics, Techniques, and Procedures +*[TLS]: Transport Layer Security +*[TSIG]: Transaction Signature +*[TVs]: Televisions +*[TV]: Television + +*[UK]: United Kingdom +*[URLs]: Uniform Resource Locators +*[URL]: Uniform Resource Locator +*[US]: United States + +*[VAR]: Vulnerability Analysis and Resolution, a process area of the CERT RMM +*[VDBs]: Vulnerability Databases +*[VDB]: Vulnerability Database +*[VDPs]: Vulnerability Disclosure Programs +*[VDP]: Vulnerability Disclosure Program +*[VINCE]: Vulnerability Information and Coordination Environment +*[Vultron]: The Vultron Protocol for CVD Interoperability +*[VMs]: Virtual Machines +*[VM]: Vulnerability Management +*[VRF]: Vulnerability Reporting Form +*[VR]: Vulnerability Response +*[VU#]: CERT Vulnerability Note +*[VXREF]: Vulnerability Cross-Reference + +*[W3C]: World Wide Web Consortium diff --git a/docs/_includes/_certcc_policy_tip.md b/docs/_includes/_certcc_policy_tip.md new file mode 100644 index 0000000..71396e0 --- /dev/null +++ b/docs/_includes/_certcc_policy_tip.md @@ -0,0 +1,11 @@ +!!! tip "Be Familiar With Our Disclosure Policy" + + You may want to review our + [Vulnerability Disclosure Policy](../reference/certcc_disclosure_policy.md). + In brief, we generally target publication of details of + the vulnerability we reported to you 45 days after our initial contact + attempt. Since our goal is a safe internet for users, we do allow some + negotiation on the timeline; feel free to contact us and discuss your + concerns. Likewise, we may disclose earlier than initially reported if + we believe there is significant evidence of current exploit of this + vulnerability. diff --git a/docs/_includes/_community_engagement.md b/docs/_includes/_community_engagement.md new file mode 100644 index 0000000..37175c9 --- /dev/null +++ b/docs/_includes/_community_engagement.md @@ -0,0 +1,31 @@ +# Community Engagement + +At the bottom of each page, you'll find a set of links to help you +interact with the CERT Guide to CVD team. You can ask questions, report +problems, request features, or join the conversation on the CERT Guide +to CVD Community Discussions. We're always looking for feedback on how +to make the site better, so don't hesitate to reach out. + +
+ +- :fontawesome-regular-comments: [**Join the conversation**](https://github.com/CERTCC/CERT-Guide-to-CVD/discussions) + + --- + Have a question or want to discuss something? Join the conversation on the CERT Guide to CVD Community Discussions. + +- :material-message-question: [**Ask a Question**](https://github.com/CERTCC/CERT-Guide-to-CVD/issues/new?template=question.md) + + --- + Have a question about the content of the site? Ask it here. + +- :fontawesome-solid-bug: [**Report a Problem**](https://github.com/CERTCC/CERT-Guide-to-CVD/issues/new?template=bug_report.md) + + --- + Found a problem with the site? Report it here. + +- :material-lightbulb-on: [**Request a Feature**](https://github.com/CERTCC/CERT-Guide-to-CVD/issues/new?template=feature_request.md) + + --- + Have an idea for a feature you'd like to see on the site? Request it here. + +
diff --git a/docs/_includes/_core_questions_of_cvd.md b/docs/_includes/_core_questions_of_cvd.md new file mode 100644 index 0000000..b0a68b1 --- /dev/null +++ b/docs/_includes/_core_questions_of_cvd.md @@ -0,0 +1,9 @@ +!!! question "The Core Questions of Coordinated Vulnerability Disclosure" + + CVD participants can be thought of as repeatedly asking these questions: + + 1. What actions should I take in response to this knowledge? + 2. Who else needs to know what, and when? + + The CVD process continues until the answers to these questions are + _nothing_, and _nobody_. diff --git a/docs/_includes/_eff_advice.md b/docs/_includes/_eff_advice.md new file mode 100644 index 0000000..a254092 --- /dev/null +++ b/docs/_includes/_eff_advice.md @@ -0,0 +1,4 @@ +!!! info "EFF Coder's Rights Project Vulnerability Reporting FAQ" + + The EFF provides some guidance on the legal aspects of the vulnerability disclosure + process in their [Coders’ Rights Project Vulnerability Reporting FAQ](https://www.eff.org/issues/coders/vulnerability-reporting-faq) diff --git a/docs/_includes/_first_psirt.md b/docs/_includes/_first_psirt.md new file mode 100644 index 0000000..9050e7c --- /dev/null +++ b/docs/_includes/_first_psirt.md @@ -0,0 +1,33 @@ +!!! info "FIRST PSIRT Services Framework" + + !!! info inline end "" + + ```mermaid + --- + title: PSIRT Services Framework + --- + + flowchart TD + subgraph sa[Service Areas] + direction TB + sa1[Stakeholder
Ecosystem
Management] + sa2[Vulnerability
Discovery] + sa3[Vulnerability
Triage] + sa4[Vulnerability
Remediation] + sa5[Vulnerability
Disclosure] + sa6[Training &
Education] + end + of[Organizational
Foundations] + of ~~~ sa + sa1 ~~~ sa2 + sa2 ~~~ sa3 + sa6 ~~~ sa4 + sa4 ~~~ sa5 + + ``` + + FIRST has published a + [PSIRT Services Framework](https://www.first.org/standards/frameworks/psirts/psirt_services_framework_v1.1) that + provides a comprehensive guide to the services that a PSIRT can provide. + It is organized into Service Areas, Services, Functions, and Sub-Functions. + The diagram at right shows the top-level Service Areas. diff --git a/docs/_includes/_mobile_supply_chain.md b/docs/_includes/_mobile_supply_chain.md new file mode 100644 index 0000000..a4488c2 --- /dev/null +++ b/docs/_includes/_mobile_supply_chain.md @@ -0,0 +1,34 @@ +!!! example "Mobile Supply Chain Example" + + !!! example inline end "" + + ```mermaid + flowchart TD + os[Mobile OS Vendor] + phone[Mobile Phone Vendor] + wireless[Wireless Carrier Vendor] + customer[Customer] + + os --> phone + phone --> wireless + wireless --> customer + ``` + + Historically, the smartphone market provides a clear example of the effect of + the software supply chain on vulnerability response. + In a 2015 [blog post](https://insights.sei.cmu.edu/blog/supporting-android-ecosystem/), + we discussed the complexity of the Android ecosystem and the challenges of coordinating vulnerability + disclosure and patch deployment in that environment at the time. + + A vulnerability in a library component used in the Android + operating system might have to be fixed by the library developer, then + incorporated into the Android project by Google, followed by the device + manufacturer updating its custom build of Android, and by the network + carrier performing its customizations and testing before finally + reaching the consumer's device. Each additional step between the party + responsible for fixing the code and the system owner (the device user, + in this case) reduces the probability that the fix will be deployed in a + timely manner, if at all. + + A generalized example of the supply chain for some mobile devices + is shown in the accompanying diagram. diff --git a/docs/_includes/_psirt_example.md b/docs/_includes/_psirt_example.md new file mode 100644 index 0000000..cbe19b0 --- /dev/null +++ b/docs/_includes/_psirt_example.md @@ -0,0 +1,10 @@ +!!! example inline end "PSIRT Examples" + + - [Microsoft Security Response Center](https://www.microsoft.com/en-us/msrc) + (MSRC) + - [Cisco PSIRT](https://sec.cloudapps.cisco.com/security/center/home.x) + - [Intel Product Security](https://www.intel.com/content/www/us/en/security-center/default.html) + - [Apple Product Security](https://www.apple.com/support/security/) + + Many vendor PSIRTs are active in the + [Forum of Incident Response and Security Teams](https://www.first.org/members/teams) (FIRST). diff --git a/docs/_includes/_quick_start.md b/docs/_includes/_quick_start.md new file mode 100644 index 0000000..7a8758f --- /dev/null +++ b/docs/_includes/_quick_start.md @@ -0,0 +1,75 @@ +# CVD Quick Start + +This is the Quick Start meta-guide for the *CERT Guide to Coordinated Vulnerability Disclosure* (CVD). + +[The *CERT Guide to CVD* in a Nutshell](../tutorials/cvd_in_a_nutshell.md) contains an +overview of the entire document, and is a good place for all readers to +become familiar with what's in the guide without necessarily poring +over the details. Where you go from there depends on what you're trying +to achieve. + +
+ +- :material-magnify: **Finders**, :material-message-alert: **Reporters**, :material-code-braces: **Vendors**, and :material-arrow-decision: **Coordinators** + + --- + + If you're a [*researcher*](../topics/roles/finder.md), + [*vendor*](../topics/roles/vendor.md), or [*coordinator*](../topics/roles/coordinator.md) trying to coordinate a disclosure and you need help, you might + want to start with + [Troubleshooting Coordinated Vulnerability Disclosure](../howto/coordination/cvd_recipes.md) + to find the problem area(s) you're currently dealing with. + From there you can follow the links into the document for more details. + +- :material-code-braces: **Vendor PSIRTs** + + --- + + If you're a [*vendor*](../topics/roles/vendor.md) trying to establish a vendor product security + incident response team (PSIRT), you may be interested in + [Principles](../topics/principles/index.md), + [Preparation](../howto/preparation/index.md), and + [Operation](../howto/operation/index.md) + as starting points. Additionally, you can use + [Troubleshooting Coordinated Vulnerability Disclosure](../howto/coordination/cvd_recipes.md) + as a rubric of scenarios to consider when planning your operational processes. + [Disclosure Policy Resources](../reference/disclosure_policy_templates.md) + contains links to a number of disclosure policy examples and + templates. + +- :material-arrow-decision: **Coordinators** + + --- + + If you're a [*coordinator*](../topics/roles/coordinator.md) spinning up your CVD capability, you + should become familiar with the + [Principles](../topics/principles/index.md), + [Roles](../topics/roles/index.md), + [Coordination](../howto/coordination/index.md), + and + [Operation](../howto/operation/index.md) sections. + The [Reference](../reference/index.md) section may also be useful to you. + +- :octicons-people-16: **Policy-Makers** + + --- + + If you're a *policy-maker* (or influencer thereof), the + sections + [HowTo Overview](../howto/index.md), + [Principles](../topics/principles/index.md), + [Roles](../topics/roles/index.md), + and [Phases](../topics/phases/index.md) are probably most useful to you + to start, but there are many edge cases in + [Troubleshooting Coordinated Vulnerability Disclosure](../howto/coordination/cvd_recipes.md) + that are worth considering when you're thinking about writing policy + that sets out how things are expected to be done. + [Disclosure Policy Resources](../reference/disclosure_policy_templates.md) + contains links to a number of disclosure policy examples and + templates. + +
+ +Of course, we think it's best if you eventually become familiar with +the entire site, but hopefully the hints above will help you find +the most effective places to start. diff --git a/docs/_includes/_report_certcc.md b/docs/_includes/_report_certcc.md new file mode 100644 index 0000000..fb0af40 --- /dev/null +++ b/docs/_includes/_report_certcc.md @@ -0,0 +1,4 @@ +!!! tip "Reporting a Vulnerability to CERT/CC" + + You can request the CERT/CC's assistance in coordinating a vulnerability disclosure process + by submitting a report through the CERT/CC's [Vulnerability Reporting Form](https://kb.cert.org/vuls/report/) (VRF). diff --git a/docs/_includes/_rmm_vm.md b/docs/_includes/_rmm_vm.md new file mode 100644 index 0000000..4d15e32 --- /dev/null +++ b/docs/_includes/_rmm_vm.md @@ -0,0 +1,3 @@ +!!! info inline end "CERT RMM: Vulnerability Analysis and Resolution (VAR)" + + {% include-markdown "./_rmm_vm_content.md" %} diff --git a/docs/_includes/_rmm_vm_content.md b/docs/_includes/_rmm_vm_content.md new file mode 100644 index 0000000..6f3a947 --- /dev/null +++ b/docs/_includes/_rmm_vm_content.md @@ -0,0 +1,25 @@ +[Vulnerability Analysis and Resolution](https://insights.sei.cmu.edu/library/vulnerability-analysis-and-resolution-var-cert-rmm-process-area/) +(VAR) is an operational process +described within the [CERT Resilience Management Model](https://insights.sei.cmu.edu/library/cert-resilience-management-model-cert-rmm-collection/) +(RMM) that closely overlaps with the concept of +Vulnerability Management. Although the RMM is designed with a focus on +operational resilience for organizations, there is sufficient overlap +with our topic that it's worth highlighting here. Within the RMM's VAR +process area, a number of goals and practices are identified: + +- Prepare for Vulnerability Analysis and Resolution. +- Establish Scope -- The assets and operational environments that must +be examined for vulnerabilities are identified. +- Establish a Vulnerability Analysis and Resolution Strategy. +- Establish and maintain a process for identifying and analyzing +vulnerabilities. +- Identify Sources of Vulnerability Information. +- Discover Vulnerabilities. +- Analyze Vulnerabilities to determine whether they need to be reduced +or eliminated. +- Manage Exposure to Vulnerabilities -- Strategies are developed and +implemented to manage exposure to identified vulnerabilities. +- Identify Root Causes -- The root causes of vulnerabilities are +examined to improve vulnerability analysis and resolution and reduce +organizational exposure. Perform review of identified +vulnerabilities to determine and address underlying causes. diff --git a/docs/_includes/_rmm_vm_wide.md b/docs/_includes/_rmm_vm_wide.md new file mode 100644 index 0000000..b36dfbf --- /dev/null +++ b/docs/_includes/_rmm_vm_wide.md @@ -0,0 +1,3 @@ +!!! info "CERT RMM: Vulnerability Analysis and Resolution (VAR)" + + {% include-markdown "./_rmm_vm_content.md" %} diff --git a/docs/_includes/_what_is_coord.md b/docs/_includes/_what_is_coord.md new file mode 100644 index 0000000..a1476e3 --- /dev/null +++ b/docs/_includes/_what_is_coord.md @@ -0,0 +1,21 @@ +!!! question "What is Coordination?" + + !!! example inline end "CERT Vulnerability Notes" + + The CERT/CC's security advisories are known as [*Vulnerability Notes*](https://www.kb.cert.org/vuls). + + Coordination is the process by which multiple parties coordinate to + share information regarding a vulnerability, with the goal of producing + a patch which fixes the vulnerability. Usually, the patch is accompanied + by a security advisory, which provides the public with information on + the vulnerability and how to apply the patch. However, in some cases, + the security advisory may be released before a patch is available. + This process at times involves several organizations. + + The CERT/CC + [coordinates](../tutorials/coord_certcc/index.md) + vulnerabilities with + [vendors](../tutorials/coord_certcc/vendor.md), + as well as provides assistance to vulnerability + [reporters](../tutorials/coord_certcc/reporter.md) + wishing to begin the coordination process for their own vulnerability. diff --git a/docs/_includes/_who_is_a_vendor.md b/docs/_includes/_who_is_a_vendor.md new file mode 100644 index 0000000..e9f6124 --- /dev/null +++ b/docs/_includes/_who_is_a_vendor.md @@ -0,0 +1,31 @@ +!!! question "Who is a Vendor?" + + As software-centric systems find their way into various industries, more + and more vendors of traditional products find themselves becoming + software vendors. + Moving beyond traditional software companies, recent years have seen the + rise in networked products and services from a variety of industries, + including those below: + + - consumer products, such as home automation and the internet of + things (IoT) + - internet service providers (ISPs) and the makers of devices that + access ISP services: internet modems, routers, access points, and + the like + - mobile phone manufacturers and service providers + - mobile application developers + - industrial control systems, building automation, HVAC manufacturers + - infrastructure suppliers and increasingly "smart" utility services + including water and sewer services and the energy industry + - transportation services, including the airline and automotive + industries + - medical devices and health-related device manufacturers + - financial services, including banks, credit card companies + - cloud service providers + - artificial intelligence and machine learning software and service providers + + Any company or organization that provides a product or service that relies on a + computer or software is referred to as a + *vendor*, + even if that organization doesn't directly make the computer or software + components used by their products. diff --git a/docs/_includes/tlp_red_amber_strict_warning.md b/docs/_includes/tlp_red_amber_strict_warning.md new file mode 100644 index 0000000..63de62c --- /dev/null +++ b/docs/_includes/tlp_red_amber_strict_warning.md @@ -0,0 +1,26 @@ +!!! warning "Use caution with **TLP:RED** and **TLP:AMBER+STRICT**" + + We have found that **TLP:RED** is too restrictive for an organization to effectively respond to a vulnerability. + For example, the analyst who receives a **TLP:RED** report might not be able to share it with their manager or their team. + In a Vendor context, this might mean that the person who receives the report cannot share it with the team responsible for fixing the vulnerability. + + **TLP:AMBER+STRICT** might be okay for a Reporter working with a single Vendor only, or when a Vendor + wants retain control over the disclosure process to other Vendors or Coordinators. + However, it limits the ability of the receiving party to engage others who might be able to help. + A Vendor in receipt of a **TLP:AMBER+STRICT** report cannot share it with their upstream or downstream Vendors. + Nor can they share it with Coordinators who might be able to help them reach other affected parties. + Similarly, a Coordinator in receipt of a **TLP:AMBER+STRICT** report cannot share it with other Coordinators or Vendors, + which severely limits their ability to assist with the coordination process. + It is not impossible to do CVD with **TLP:AMBER+STRICT**, but it is more difficult and less effective. + + Therefore we recommend **TLP:AMBER** for most cases prior to public disclosure. + + **TLP:GREEN** can be useful for cases nearing public disclosure, for example when necessary to engage critical infrastructure + through ISACs, ISAOs, or other trusted channels. In some larger multiparty cases, **TLP:GREEN** might be useful to reach + a broader audience of potentially affected vendors, deployers and other stakeholders. However, the use of **TLP:GREEN** + should be carefully considered, as it may be more likely to lead to unintended public disclosure. + + **TLP:CLEAR** is more appropriate for cases where the vulnerability is already public. + + Finally, we observe that CVD is usually geared towards eventually reaching **TLP:CLEAR**, with **TLP:GREEN** being sometimes + a necessary stopping-off point for certain stakeholders. diff --git a/docs/about.md b/docs/about.md new file mode 100644 index 0000000..ace75e4 --- /dev/null +++ b/docs/about.md @@ -0,0 +1,68 @@ +# About This Guide + +
+ +!!! note "What This Guide Is" + + This is a summary of what we know about a complex social process that + surrounds humans trying to make the software and systems they use more + secure. It's about what to do (and what not to) when you find a + vulnerability, or when you find out about a vulnerability. It's written + for vulnerability analysts, security researchers, developers, and + deployers; it's for both technical staff and their management alike. + While we discuss a variety of roles that play a part in the process, we + intentionally chose not to focus on any one role; instead we wrote for + any party that might find itself engaged in coordinating a vulnerability + disclosure. + + We wrote it in an informal tone to make the content more approachable, + since many readers' interest in this documentation may have been prompted by + their first encounter with a vulnerability in a product they created or + care about. The informality of our writing should not be construed as a + lack of seriousness about the topic, however. + + In a sense, this documentation is a travel guide for what might seem a foreign + territory. Maybe you've passed through once or twice. Maybe you've only + heard about the bad parts. You may be uncertain of what to do next, + nervous about making a mistake, or even fearful of what might befall + you. If you count yourself as one of those individuals, we want to + reassure you that you are not alone; you are not the first to experience + events like these or even your reaction to them. We're locals. We've + been doing this for a while. Here's what we know. + +!!! note "What This Guide Is Not" + + - *This is not a technical document.* You will not learn anything new about + fuzzing, debugging, ROP gadgets, exploit mitigations, heap spraying, + exception handling, or anything about how computers work by reading this + report. What you will learn is what happens to that knowledge and how + its dissemination is affected by the human processes of communications + and social behavior in the context of mitigating and remediating security + vulnerabilities. + + - _This is not a history._ We won't spend much time at all on the history of + disclosure debates, or the fine details of whether collecting or + dropping zero-days is always good or always bad. We will touch on these + ideas only insofar as they intersect with the current topic of + coordinated vulnerability disclosure. + + - _This is not an indictment._ We are not seeking to place blame on one + party or another for the success or failure of any given vulnerability + disclosure process. We've seen enough disclosure cases to know that + people make choices based on their own values coupled with their + assessment of a situation, and that even in cases where everyone agrees + on what should happen, mistakes and unforeseeable events sometimes alter + the trajectory from the plan. + + - _This is not a standard._ We assert no authority to bless the information + here as "the way things ought to be done." In cases where standards + exist, we refer to them, and this documentation is informed by them. In fact, + we've been involved in creating some of them. But the recommendations + made in this documentation should not be construed as "proper," "correct," or + "ideal" in any way. As we'll show, disclosing vulnerabilities presents a + number of difficult challenges, with long-reaching effects. The + recommendations found here do, however, reflect our observation over the + past few decades of what works (and what doesn't) in the pursuit of + reducing the vulnerability of software and related products. + +
diff --git a/docs/about/acknowledgements.md b/docs/about/acknowledgements.md new file mode 100644 index 0000000..715fcae --- /dev/null +++ b/docs/about/acknowledgements.md @@ -0,0 +1,26 @@ +# Acknowledgements + +The material in the CERT® Guide to Coordinated Vulnerability Disclosure +inherits from over three decades of analyzing vulnerabilities and navigating +vulnerability disclosure issues at the CERT Coordination Center +(CERT/CC). While a few of us may be the proximate authors of the words +you are reading, many of the ideas these words represent have been +bouncing around at CERT for years in one brain or another. We'd like to +acknowledge those who contributed their part to this endeavor, whether +knowingly or not: + +Jared Allar, Jeff Carpenter, Cory Cohen, Roman Danyliw, Will Dormann, +Chad Dougherty, James T. Ellis, Ian Finlay, Bill Fithen, Jonathan Foote, +Jeff Gennari, Ryan Giobbi, Jeff Havrilla, Shawn Hernan, Allen +Householder, Chris King, Dan Klinedinst, Joel Land, Jeff Lanza, Todd +Lewellen, Frank Longo, Navika Mahal, Art Manion, Joji Montelibano, Trent +Novelly, Madison Oliver, Michael Orlando, Ally Parisi, Rich Pethia, Jeff +Pruzynski, Robert Seacord, Deana Shick, Stacey Stewart, David Warren, +and Garret Wassermann + +We also acknowledge the contributions of + +- the broader [CERT Division](https://www.sei.cmu.edu/about/divisions/cert/), part of the [Software Engineering Institute](https://www.sei.cmu.edu) at [Carnegie Mellon University](https://www.cmu.edu) +- the [GitHub community](https://github.com/CERTCC/CERT-Guide-to-CVD/graphs/contributors) + +who have provided feedback and suggestions that have helped shape this documentation. diff --git a/docs/about/community.md b/docs/about/community.md new file mode 100644 index 0000000..192baf9 --- /dev/null +++ b/docs/about/community.md @@ -0,0 +1 @@ +{% include-markdown "../_includes/_community_engagement.md" %} diff --git a/docs/about/conclusion.md b/docs/about/conclusion.md new file mode 100644 index 0000000..10caff0 --- /dev/null +++ b/docs/about/conclusion.md @@ -0,0 +1,59 @@ +# Conclusion + +The scope of the population affected by cybersecurity vulnerabilities +has widened considerably in recent years. +In the past, one might have argued that only computer users were +affected by vulnerabilities and their disclosure: this is no longer the +case. Affected users now include those who have smartphones, watch smart +TVs, use credit cards or ATMs for banking and/or shopping, drive cars, +fly in airplanes, go to the hospital for diagnostic imaging or +intravenous medicine, live in houses with smart meters, and so forth. +The list goes on to include nearly everyone, and "opting out" is not a +viable position for most people to take. + +In an ideal world, software would do exactly what we expect it to do, and nothing we don't want it +to do. + +In an ideal world, vendors would be receptive to finding out +about vulnerabilities in their products, and would recognize the service +provided to them by those who find and report problems. They would be +motivated to place user safety, privacy, and security at the top of +their priorities. + +In an ideal world, human communications would be clear +to all parties involved. Well-meaning parties would never misunderstand +or misinterpret each other's words or intentions. People would always +be polite, patient, humble, calm, without guile, and willing to put +aside their own interests for those of others. + +We do not live in an ideal world. + +In the world we find ourselves occupying, software-based +systems exhibit complex behaviors, increasingly exceeding the limits of +human comprehension[^1]. +As a society, we have become capable of building things we don't +fully understand. The difference between *what a thing does* and *what you +expect it to do* can lead to uncertainty, confusion, fear, and +vulnerability. + +But it's not just the technology that falls short of our ideals. +It should come as no surprise that humans have diverse emotions and motives. +Values differ. +Feelings get hurt, people get frustrated. +Words are misinterpreted. +Incentives promote individual choices that conflict with each other. +What's good for the individual is sometimes bad for the collective, and vice-versa. + +And so, we're left to muddle through. +To confront each day as an opportunity to learn, another chance +to improve, and make tomorrow start a little better than yesterday +ended. +We scan the horizon to reduce surprise. +We test for flaws, we probe for weaknesses, and we identify recurring patterns and themes that +lead to undesired outcomes. +We fix what we can, mitigate what we can't fix, and remain vigilant over what we can't mitigate. +We coordinate vulnerability disclosure because we realize we're all in this together. + +Thanks for reading. + +[^1]: Samuel Arbesman, *Overcomplicated: Technology at the Limits of Comprehension*, Portfolio/Penguin, 2017. diff --git a/docs/about/contributing.md b/docs/about/contributing.md new file mode 100644 index 0000000..c8af9a5 --- /dev/null +++ b/docs/about/contributing.md @@ -0,0 +1 @@ +{% include-markdown "../../CONTRIBUTING.md" %} diff --git a/docs/about/copyright.md b/docs/about/copyright.md new file mode 100644 index 0000000..a3960c0 --- /dev/null +++ b/docs/about/copyright.md @@ -0,0 +1 @@ +{% include-markdown "../../COPYRIGHT.md" %} diff --git a/docs/about/sightings.md b/docs/about/sightings.md new file mode 100644 index 0000000..61a79b6 --- /dev/null +++ b/docs/about/sightings.md @@ -0,0 +1,24 @@ +!!! info "Sightings" + + Here is a partial list of places The CERT Guide to Coordinated + Vulnerability Disclosure has appeared. + + ------------------------------------------------------------------------ + + - 2021-06-24 - [See Something, Say Something: Coordinating the Disclosure of Security Vulnerabilities in Canada](https://www.cybersecurepolicy.ca/vulnerability-disclosure) (Cyberspace Policy Exchange) + - 2020-03-23 - [The CERT Guide to Coordinated Vulnerability Disclosure](https://insights.sei.cmu.edu/library/the-cert-guide-to-coordinated-vulnerability-disclosure/) (SEI Podcast) + - 2019-09-17 - [Update on the CERT Guide to Coordinated Vulnerability Disclosure](https://insights.sei.cmu.edu/blog/update-on-the-cert-guide-to-coordinated-vulnerability-disclosure/) - (Software Engineering Institute) + - 2018-12-14 - [Economics of Vulnerability Disclosure](https://www.enisa.europa.eu/publications/economics-of-vulnerability-disclosure) (ENISA) + - 2018-10-23 - [The Criticality of Coordinated Disclosure in Modern Cybersecurity](https://web.archive.org/web/20230114003158/https://republicans-energycommerce.house.gov/wp-content/uploads/2018/10/10-23-18-CoDis-White-Paper.pdf) (US House Energy and Commerce Committee, Majority Staff) + - 2018-10-10 - [Announcing Arduino's Coordinated Vulnerability Disclosure Policy](https://blog.arduino.cc/2018/10/10/announcing-arduino-coordinated-vulnerability-disclosure-policy/) (Arduino) + - 2018-09-18 - [It Takes a Village: How Hacktivity Can Save Your Company](https://publications.atlanticcouncil.org/hacktivity/) (Atlantic Council) + - 2018-07-26 - [SEI Response to Senate and House Committees regarding Coordinated Vulnerability Disclosure](https://web.archive.org/web/20200810085618/https://republicans-energycommerce.house.gov/wp-content/uploads/2018/08/CERT-Response-MultiParty-CVD-Congressional-Letter.pdf) (Software Engineering Institute) + - 2018-07-17 - [Letter to SEI from House Committee on Energy and Commerce and Senate Committee on Commerce, Science, and Transportation regarding Coordinated Vulnerability Disclosure](https://web.archive.org/web/20230112063739/https://republicans-energycommerce.house.gov/wp-content/uploads/2018/07/071718-SEI-Spectre-Meltdown.pdf) (US House & Senate) + - 2018-07-11 - [Senate Testimony regarding Complex Cybersecurity Vulnerabilities: Lessons Learned from Spectre and Meltdown](https://www.commerce.senate.gov/public/index.cfm/hearings?Id=77835497-EC96-41E8-B311-5AF789F38422&Statement_id=518CD2D5-87E5-4A64-B619-7E09C85174AF) (Art Manion's testimony to the US Senate) + - 2018-06-28 - [Software Vulnerability Disclosure in Europe: Technology, Policies and Legal Challenges](https://www.ceps.eu/ceps-publications/software-vulnerability-disclosure-europe-technology-policies-and-legal-challenges/) (Centre for European Policy Studies) + - 2018-02-07 - [Response to US House Energy and Commerce Committee regarding Meltdown and Spectre](https://web.archive.org/web/20180924112647/https://energycommerce.house.gov/wp-content/uploads/2018/02/MSFT-Spectre-Response-to-EC-Committee-.pdf) (Microsoft) + - 2018-01-31 - [Response to US House Energy and Commerce Committee regarding Meltdown and Spectre](https://web.archive.org/web/20180924112525/https://energycommerce.house.gov/wp-content/uploads/2018/02/Intel-Corp-response-HEC-FINAL.pdf) (Intel) + - 2017-11-28 - [AMA with Authors of The CERT Guide to Coordinated Vulnerability Disclosure](https://youtu.be/oshHrujqPjc) (HackerOne) + - 2017-10-26 - [Your TL;DR Summary of the CERT Guide to Coordinated Vulnerability Disclosure](https://www.hackerone.com/blog/Your-TLDR-Summary-of-The-CERT-Guide-to-Coordinated-Vulnerability-Disclosure) (HackerOne) + - 2017-08-16 - [This one matters, too: Carnegie Mellon issues guide to disclosing software vulnerabilities responsibly](https://www.cyberscoop.com/carnegie-mellon-sei-cert-vulnerability-disclosure/) (cyberscoop) + - 2017-08-15 - [CERT Guide to Coordinated Vulnerability Disclosure Released](https://insights.sei.cmu.edu/news/cert-guide-to-coordinated-vulnerability-disclosure-released/) (Software Engineering Institute) diff --git a/docs/assets/cert.png b/docs/assets/cert.png new file mode 100644 index 0000000..60f9452 Binary files /dev/null and b/docs/assets/cert.png differ diff --git a/docs/assets/cert_seal.svg b/docs/assets/cert_seal.svg new file mode 100644 index 0000000..980c324 --- /dev/null +++ b/docs/assets/cert_seal.svg @@ -0,0 +1 @@ +cert_seal \ No newline at end of file diff --git a/docs/howto/coordination/_report_credibility.md b/docs/howto/coordination/_report_credibility.md new file mode 100644 index 0000000..07ae95f --- /dev/null +++ b/docs/howto/coordination/_report_credibility.md @@ -0,0 +1,90 @@ +# Report Credibility + +!!! ssvc inline end "SSVC's Report Credibility Decision Point" + + The content in this section is adapted from the CERT/CC's [Stakeholder-Specific Vulnerability Categorization (SSVC)](https://certcc.github.io/SSVC/) + [Report Credibility Decision Point](https://certcc.github.io/SSVC/reference/decision_points/report_credibility/) documentation. + +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 report credibility + depends on a balancing test among the following indicators. + +!!! tip "Indicators for Credibility" + + Indicators in favor of credibility include when the report + + - is specific about what is affected + - provides sufficient detail to reproduce the vulnerability. + - describes an attack scenario. + - suggests mitigations. + - includes proof-of-concept exploit code or steps to reproduce. + - neither exaggerates nor understates the impact. + + Additionally, screenshots and videos, if provided, support the written text of the report and do not replace it. + +!!! warning "Indicators against Credibility" + + Indicators against credibility include when the report + + - is “spammy” or exploitative (for example, the report is an attempt to upsell the receiver on some product or service). + - 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). + - is vague or ambiguous about the preconditions necessary to exploit the vulnerability. + - is vague or ambiguous about the impact if exploited. + - exaggerates the impact if exploited. + - 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). + - 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. + - 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). + - 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. + - 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. + - conspicuously misuses technical terminology. This is evidence that the reporter may not understand what they are talking about. + - consists of mostly raw tool output. Fuzz testing outputs are not vulnerability reports. + - lacks sufficient detail for someone to reproduce the vulnerability. + - 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. + - describes a bug with no discernible security impact. + - fails to describe an attack scenario, and none is obvious. + + Two additional indicators of non-credible reports are: + + - The reporter is known to have submitted low-quality reports in the past. + - The analyst’s professional colleagues consider the report to be not credible. + +!!! question "Why isn't poor grammar on this list?" + + 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 receiver'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 + +We are 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 prioritization 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/howto/coordination/active_exploitation.md b/docs/howto/coordination/active_exploitation.md new file mode 100644 index 0000000..41810d2 --- /dev/null +++ b/docs/howto/coordination/active_exploitation.md @@ -0,0 +1,22 @@ +# Active Exploitation + +If evidence comes to light that a vulnerability is being exploited in +the wild, that is usually a strong indication to accelerate the +disclosure timeline. + +!!! tip "Active Exploitation Should Accelerate Disclosure" + + Active exploitation is indicative of either [independent discovery](./independent_discovery.md) or an + [information leak](./leaks.md) from the CVD process (whether intentional or + accidental), with the added concern that not only does an adversary know + about the vulnerability but is already using it. + + Hence, in the case of known exploitation, it's usually best to consider + disclosing what is known about the vulnerability—hopefully with some + mitigation instructions—as soon as possible even if a patch is not yet + available. From the vendor's standpoint, acknowledging that you're + already aware of the vulnerability and are working on a fix can help + restore users' confidence in your product and the process that produced + it. + +{% include-markdown "../recipes/_x02.md" heading-offset=1 %} diff --git a/docs/howto/coordination/coordinator_reasons.md b/docs/howto/coordination/coordinator_reasons.md new file mode 100644 index 0000000..fc9d760 --- /dev/null +++ b/docs/howto/coordination/coordinator_reasons.md @@ -0,0 +1,96 @@ +# Reasons to Engage a Coordinator + +There are a number of reasons that a finder, reporter, or vendor may +wish to engage a third-party coordinator to assist with the CVD process. +Reporter experience, capacity, and the number or nature of vendors +involved can all play a role in determining whether a coordinator is +needed. In addition, disputes between reporters and vendors, or the +potential for major infrastructure impacts, can also necessitate the +involvement of a coordinator. + +## Reporter Inexperience + +Novice reporters sometimes request assistance from coordinators to +increase the chances of a successful resolution to the vulnerability +they have found. Working with a coordinator for the first few cases can +help develop a reporter's knowledge of the CVD process. From the +coordinator's perspective, working with novice reporters serves to +transfer knowledge of CVD to the security research community, thereby +improving vulnerability response overall. We have found that novice +reporters usually learn quickly and are willing to do most of the +coordination effort themselves, but just need occasional advice on how +the process should work. + +## Reporter Capacity + +Seeing a CVD case through to resolution can at times be a protracted +process. Not all reporters have the time or resources to follow up on +vulnerabilities they've reported. In such situations, a coordinator can +help by offloading some of the effort. However, coordinators are often +limited in their capacity as well, and must accordingly prioritize the +cases they choose to take on. As a result, coordinators and reporters +alike should take care to set clear expectations with each other as to +what roles they expect to play in any given coordination case. + +{% include-markdown "../recipes/_x01.md" heading-offset=1 %} + +## Multiple Vendors Involved + +At its most effective, CVD follows the supply chain affected by the +vulnerability. As a mental model, it can be useful to think of the +supply chain as horizontal or vertical. A horizontal supply chain +implies that many vendors need to independently make changes to their +products in order to fix a vulnerability. A vertical supply chain +implies that one vendor might originate the fix, but many other vendors +may need to update their products after the original fix is available. +Software libraries tend to have vertical supply chains. Protocol +implementations often have horizontal supply chains. + +We discuss horizontal and vertical supply chains in [Multiparty CVD](mpcvd.md). + +{% include-markdown "../recipes/_x09.md" heading-offset=1 %} + +## CVD Disputes + +Occasionally vendors and reporters have difficulty arriving at a +mutually acceptable response to the existence of a vulnerability. + +Disputes can arise for many reasons, including the following: + +- Whether the behavior described in the report is reproducible +- Whether the behavior described in the report has security + implications +- The impact of the vulnerability to deployed systems +- Whether to publicly disclose the vulnerability +- How much detail to include in a public disclosure +- The timing of public disclosure +- Whether extensions should be made to deadlines set by one party or + another, whether or not they have been mutually agreed to previously + +In these situations, and many others, reporters and/or vendors may find +it useful to engage the services of a third-party coordinator to assist +with conflict resolution. Drawing on the experience and relative +neutrality of a third-party coordinator can often dissipate some of the +potential animosity that can arise in contentious cases. + +{% include-markdown "../recipes/_x21.md" heading-offset=1 %} + +## Major Infrastructure Impacts + +In situations where a vulnerability has the potential for major impact +to critical infrastructure, it may be necessary to coordinate not only +with vendors to fix the vulnerable products, but also with major +deployers. The primary concern in these cases is to ensure that internet +and other critical infrastructure remains available so that deployers +and other network defenders can acquire and deploy the necessary +information and patches. + +Luckily this scenario is rare, but we have seen it come up in cases +affecting internet routing, the Domain Name System (DNS), internet +protocols, and the like. Vulnerabilities that affect basic Internet +services such as DNS (which also serves as an example of a horizontal +supply chain) affect a massive number of vendors; a coordinator can help +contact and disseminate information to vendors, service providers, and +other critical organizations for quick remediation or mitigation. + +{% include-markdown "../../_includes/_report_certcc.md" heading-offset=1 %} diff --git a/docs/howto/coordination/cvd_recipes.md b/docs/howto/coordination/cvd_recipes.md new file mode 100644 index 0000000..3471680 --- /dev/null +++ b/docs/howto/coordination/cvd_recipes.md @@ -0,0 +1,66 @@ +# Troubleshooting Coordinated Vulnerability Disclosure + +We have compiled a list of common problems that can arise during the Coordinated Vulnerability Disclosure (CVD) process. +Each problem identified is accompanied by a description intended to help the reader diagnose the problem. +The list is organized according to the roles affected and the phases in which the problem is likely to arise. + +In addition to the advice found below, we encourage readers to be familiar with our [General Tips](./general_tips.md). + +
+ +- :material-gauge-empty: [Finder does not have the resources to shepherd a CVD case through to resolution](#01) +- :material-fire-alert: [Evidence of exploitation for an embargoed report](#02) +- :material-phone-missed: [Unable to engage vendor contact](#03) +- :material-bank-off: [Vendor does not have a posted bug bounty](#04) +- :fontawesome-solid-road-spikes: [Vendor has a reputation for or history of treating reporters poorly](#05) +- :material-delete-variant: [Vendor explicitly declines to take action on a report](#07) +- :material-phone-hangup: [Vendor stops responding](#06) +- :material-phone-hangup: [Reporter stops responding](#10) +- :material-progress-clock: [Vendor is unprepared for pending embargo expiration](#08) (Reporter, Coordinator perspective) +- :material-progress-clock: [Vendor is unprepared for pending embargo expiration](#19) (Vendor perspective) +- :material-crowd: [A CVD case involves too many vendors or is otherwise excessively complex.](#09) +- :material-newspaper: [Vulnerability becomes public prior to vendor intended date](#11) +- :fontawesome-solid-face-surprise: [Vulnerability becomes public prior to vendor awareness of the vulnerability](#12) +- :material-border-outside: [Vendor receives report outside the scope of their reporting program](#13) +- :fontawesome-solid-face-angry: [Vendor suspects the finder violated its policy in the process of finding a vulnerability.](#14) +- :material-content-duplicate: [Vendor receives second report of a vulnerability already under embargo](#15) +- :material-arrow-oscillating: [Vulnerability affects downstream vendors](#16) +- :material-account-question: [Vulnerability affects unknown downstream vendors](#17) +- :material-gate-xor: [Vulnerability affects multiple vendors with incompatible disclosure policies](#18) +- :material-bullhorn: [A vulnerability is receiving unanticipated media attention](#20) +- :material-emoticon-sick: [A CVD case just isn't going well](#21) + +
+ +Did you notice something we missed in this list? +We're taking [suggestions](https://github.com/CERTCC/CERT-Guide-to-CVD/issues). + +## CVD Problem-Solving Recipe Cards + +{% include-markdown "../recipes/_recipe_explainer.md" heading-offset=1 %} + +--- + +{% include-markdown "../recipes/_x01.md" heading-offset=1 %} +{% include-markdown "../recipes/_x02.md" heading-offset=1 %} +{% include-markdown "../recipes/_x03.md" heading-offset=1 %} +{% include-markdown "../recipes/_x04.md" heading-offset=1 %} +{% include-markdown "../recipes/_x05.md" heading-offset=1 %} +{% include-markdown "../recipes/_x07.md" heading-offset=1 %} +{% include-markdown "../recipes/_x06.md" heading-offset=1 %} +{% include-markdown "../recipes/_x10.md" heading-offset=1 %} +{% include-markdown "../recipes/_x08.md" heading-offset=1 %} +{% include-markdown "../recipes/_x19.md" heading-offset=1 %} +{% include-markdown "../recipes/_x09.md" heading-offset=1 %} +{% include-markdown "../recipes/_x11.md" heading-offset=1 %} +{% include-markdown "../recipes/_x12.md" heading-offset=1 %} +{% include-markdown "../recipes/_x13.md" heading-offset=1 %} +{% include-markdown "../recipes/_x14.md" heading-offset=1 %} +{% include-markdown "../recipes/_x15.md" heading-offset=1 %} +{% include-markdown "../recipes/_x16.md" heading-offset=1 %} +{% include-markdown "../recipes/_x17.md" heading-offset=1 %} +{% include-markdown "../recipes/_x18.md" heading-offset=1 %} +{% include-markdown "../recipes/_x20.md" heading-offset=1 %} +{% include-markdown "../recipes/_x21.md" heading-offset=1 %} + +{% include-markdown "../../_includes/_report_certcc.md" heading-offset=1 %} diff --git a/docs/howto/coordination/disclosure_timing.md b/docs/howto/coordination/disclosure_timing.md new file mode 100644 index 0000000..1d67149 --- /dev/null +++ b/docs/howto/coordination/disclosure_timing.md @@ -0,0 +1,145 @@ +# Disclosure Timing + +How long is "long enough" to respond to a vulnerability? +As with so many questions that arise in the CVD process, there is no +single right answer. + +!!! question "How long is long enough?" + + Is 45 days long enough? Is 90 days too short? Is 217 days unreasonable? Three + years? + The only answer we can give is "It depends." + + Complicated vulnerabilities usually take longer to fix. + Larger cases involving more parties, more products, or more complex + supply chains also tend to take longer to resolve, even if the + vulnerabilities themselves are relatively simple. + +So rather than trying to solve an underspecified problem, let's have a look at some of the factors that tend +to play into timing choices. This will give us an opportunity to see where some of the variability comes from. + +!!! tip "Conference Schedules Often Drive Disclosure Timing" + + Conference schedules often drive researcher timelines. + There is a rhythmic cycle to the vulnerability disclosure calendar. + [Black Hat](https://www.blackhat.com/) and [DEF CON](https://www.defcon.org/) happen in early August every year. + [Usenix Security](https://www.usenix.org/conferences/byname/108) is usually right after that. The [RSA Conference](https://www.rsaconference.com/) + is in the late winter or early spring. [CanSecWest](https://cansecwest.com/) is in the + spring. Smaller conferences are scattered in between. + + + ```mermaid + timeline + Spring: RSA : CanSecWest : Black Hat Asia + Summer: Black Hat USA : DEFCON : USENIX + Autumn: Black Hat Middle East/Africa + Winter: Black Hat Europe + ``` + + Many of these + conferences rely on presenters describing novel attack methods in + varying degrees of detail. However, in order for researchers to analyze, + develop, and demonstrate those techniques, vulnerabilities are often + uncovered in extant products. That means that coordinating the + disclosure of the vulnerabilities they've found is a common part of the + conference preparation process for presenters. The CERT/CC often + observes an increased rate of vulnerability reports a few months in + advance of these conferences. Vendors would do well to be aware of these + schedules and be prepared to respond quickly and appropriately to + seemingly inflexible deadlines for + disclosure. + +!!! warning "Vendor Reputation and Willingness to Cooperate" + + Vendors that are perceived to treat vulnerability reporters poorly or + that are perceived to be slow or unresponsive may find themselves being + left to discover reports of vulnerabilities in their products at the + same time as the public becomes aware of them. CVD is a social process, + remember? And the game is played over and over, by players who share + knowledge between rounds. + +!!! tip "Declarative Disclosure Policies Reduce Uncertainty" + + [Avoiding surprise](../../topics/principles/avoid_surprise.md) is one of + the principles of CVD. + To that end, explicitly declared policies (from both researchers and + vendors) are a good thing. Expected disclosure timing is an important + question to ask whenever a report is received. Sometimes the reporter or + coordinator acting on the reporter's behalf has a standing policy of X + days with no exceptions. Other reporters may be more flexible. If in + doubt, ask. + +## Diverting from the Plan + +Plans are one thing, but reality sometimes disagrees with our assessment +of it. Breaking a previous disclosure timeline agreement is sometimes +necessary when events warrant. Below we cover a few reasons to release +earlier or later than planned. + +!!! example "Reasons to release early" + + - Evidence of active exploitation + - Vendor fails to respond, is not acting in good faith, or denies the + existence of a vulnerability + - Vulnerability is known to be discovered by adversaries, so the race + to defend vulnerable systems is more focused + - All known users have been notified and patched (usually via private + channels) + +!!! example "Reasons to hold back release" + + - Vendor not ready with fix, but continuing to make progress and is + acting in good faith + - Vulnerabilities with severe impact, especially those affecting + safety-critical or critical infrastructure + - Cases where new information is found late in the process, for + example that there are important but previously unrecognized + dependencies that alter the impact of the vulnerability or patch + deployability + +In cases that divert from the planned disclosure date, it sometimes +helps to seek the opinion of a neutral third party for advice on how to +proceed. Finders, reporters, and vendors can each have valid yet +conflicting perspectives on what the best course of action might be. +Coordinator organizations are often able to help resolve conflicts by +taking a neutral approach to the situation and advising one or more +parties in light of their prior experience. + +!!! warning "All Disclosure Agreements Are Contingent" + + When vendors, reporters, and/or coordinators negotiate and agree to a + release timeline for a vulnerability, they may behave as if they've + reached some state of détente with the world. But that's an illusion. + True, they may have reached an agreement with each other, but it ignores + another relevant role in the disclosure process: the adversary. + + Adversaries do not care whether the vendor plans to release the patch in + a month, whether they need more time to test it prior to release, + whether the reporter wants to break the news at a conference event, + whether the reporter hopes to get paid for the work, or any other reason + that reporters and vendors may have for agreeing to the terms they came + to. + + Furthermore, because the vulnerability's existence is an observable + fact in the world, anyone else who happens to notice it might also + choose to disclose that knowledge on their own terms without being party + to any existing embargo agreements. + + Therefore it's important for + vendors, reporters, and coordinators alike to recognize that all + disclosure embargo agreements are necessarily contingent on + circumstances beyond the control of the parties involved; and that those + circumstances are not simply random events but may be controlled by + actors who are indifferent to their concerns. + +!!! warning "Releasing Partial Information Can Help Adversaries" + + When considering what information to release about a vulnerability, our + advice is "Don't tease." Our experience shows that the mere knowledge + of a vulnerability's existence in a feature of some product is + sufficient for a skillful person to discover it for themselves. Rumor of + a vulnerability draws attention from knowledgeable people with + vulnerability finding skills—and there's no guarantee that all those + people will have users' best interests in mind. Thus, teasing the + existence of a vulnerability in a product can sometimes provide an + adversarial advantage that increases risk to end users. diff --git a/docs/howto/coordination/general_tips.md b/docs/howto/coordination/general_tips.md new file mode 100644 index 0000000..d22d679 --- /dev/null +++ b/docs/howto/coordination/general_tips.md @@ -0,0 +1,108 @@ +# What to Do When Things Go Wrong + +While we can't tell you what to do in every possible combination of +contingencies that may arise in the CVD process, we can suggest a few +guidelines to help you navigate the complexity. + +!!! tip "Keep Calm and Carry On" + + Although problems with the disclosure process can be stressful, it's + better to keep emotions in check while resolving issues. Recall from + [Presume Benevolence](../../topics/principles/presume_benevolence.md) + that a presumption + of benevolence is helpful when navigating the CVD process. As we have + described in [CVD Problem Solving](index.md), + multiple things can go wrong in the disclosure process, but often these + problems do not arise as a result of intentional acts of malice. So even + if something has gone wrong, it's still good to give the benefit of the + doubt to the good intentions of the involved stakeholders. + +!!! tip "Avoid Legal Entanglements" + + Whatever the issue is in the context of a vulnerability disclosure, + lawyers alone are rarely the right answer. Cease-and-desist letters tend + to backfire as described in [Hype](hype.md). + + Responding with legal threats can have negative public relations effects + in the long term for vendors as well: + + - It gives the appearance that the vendor is more concerned about protecting its image than users' security. + - It can give the impression that the organization is bullying an individual. + - It can drive future researchers away from reporting the vulnerabilities they find. + +
+ +!!! tip "Recognize the Helpers: Vendors" + + A person who shows up at your door to tell you about a + vulnerability in your product is not the enemy. That person is your + friend. + +!!! tip "Recognize the Helpers: Finders/Reporters" + + A vendor who is responsive is doing better than many. + +
+ +!!! tip "Recognize the Helpers: Everyone" + + !!! example inline end "CVD Motivations" + + [I am the Cavalry](https://www.iamthecavalry.org/motivations/) lists five motivations for security researchers: + Protect, Puzzle, Prestige, Profit, and Protest/Patriotism. + + Give credit where it's due. + Many participants in CVD are there because they care about making things better. + Recognizing them for their good work keeps them engaged and helps everybody in the long run. + +!!! tip "Consider Publishing Early" + + Recall that the goal of CVD is to help users make more informed + decisions about actions they can take to secure their systems. Sometimes + it becomes obvious that the coordination of a disclosure has failed. In + these cases, it may make more sense to publish earlier than expected + than to continue to withhold information from those who could use it to + defend their systems. + + See also [Leaks](leaks.md), [Independent Discovery](independent_discovery.md), and [Active Exploitation](active_exploitation.md). + +!!! tip "Engage a Third-Party Coordinator" + + !!! example inline end "Third-Party Coordinators" + + Examples of third-party coorinators include the following: + + - CERT/CC + - National CSIRTs that handle CVD cases + - JPCERT/CC + - NCSC-FI + - NCSC-NL + - Larger vendors (Google, Microsoft, etc.) + - Bug bounty operators (BugCrowd, HackerOne, etc.) + + We have outlined a variety of ways in which the CVD process might not go + as smoothly as you'd like, whether you are a finder, reporter, vendor, + coordinator, or deployer. When problems arise that you're not prepared + to handle, or even if you just need a quick opinion on what to do next, + there are a number of coordinating organizations available to help. + +!!! tip "Learn from the Experience" + + !!! example inline end "Retrospective Questions" + + As an example of questions to begin a retrospective discussion, consider + this list derived from the [Scrum Alliance](https://resources.scrumalliance.org/Article/sprint-retrospective): + + - What went well? + - What went wrong? + - What could we do differently to improve? + + Any process worth doing more than once is one worth improving. To that + end, we recommend that participants in CVD take good notes. Hold a + retrospective to identify things that went well, things that didn't, + and explore changes you can make to your process for next time. This + very document is in large part the result of notes taken during + "lessons learned" sessions with vulnerability coordinators at the + CERT/CC. + +{% include-markdown "../../_includes/_report_certcc.md" heading-offset=1 %} diff --git a/docs/howto/coordination/hype.md b/docs/howto/coordination/hype.md new file mode 100644 index 0000000..ac52aa2 --- /dev/null +++ b/docs/howto/coordination/hype.md @@ -0,0 +1,56 @@ +# Hype, Marketing, and Unwanted Attention + +!!! example inline end "Branded Vulnerabilities" + + In recent years we've witnessed the rise of branded vulnerabilities, including + [Heartbleed](https://nvd.nist.gov/vuln/detail/CVE-2014-0160), + [Poodle](https://nvd.nist.gov/vuln/detail/CVE-2014-3566), + [Badlock](https://nvd.nist.gov/vuln/detail/CVE-2016-2118), + [Shell Shock](https://nvd.nist.gov/vuln/detail/CVE-2014-6271), + [GHOST](https://nvd.nist.gov/vuln/detail/CVE-2015-0235), + [Spectre and Meltdown](https://nvd.nist.gov/vuln/detail/CVE-2017-5753). + +Is a branded vulnerability more dangerous than one without? +Not in any technical sense, no. Instead, what it does is +draw additional attention—which can lead to vendors being +forced to adjust the priority of the vulnerability cases they're +working on and allocate resources toward addressing whatever +vulnerability is getting the hype. + +!!! question "Are branded vulnerabilities good or bad for internet security?" + + The only good answer is the lesson of the Taoist [parable of the farmer and the horse](https://en.wikipedia.org/wiki/The_old_man_lost_his_horse): "Maybe." + +## The Streisand Effect + +Attempts to squash true information once it's been revealed tends not +only to spread the information more widely, but also to backfire on +whoever is trying to conceal it. +The [name](https://www.techdirt.com/articles/20150107/13292829624/10-years-everyones-been-using-streisand-effect-without-paying-now-im-going-to-start-issuing-takedowns.shtml), +coined by [Mike Masnick](https://www.techdirt.com/user/mmasnick/), +comes from a case involving +the removal of online photos of a famous celebrity's house. The +attempt to suppress the photos only drew attention to them resulting in +many more people seeing them than would have otherwise. + +This scenario comes up from time to time in CVD cases. Often it takes +the form of a vendor trying to suppress the publication of a report +about a vulnerability in its product, with some threat of legal action +if the information is released. As we've discussed previously, the +knowledge that a vulnerability exists in some feature of a product can +be sufficient for a knowledgeable individual to rediscover the +vulnerability. The legal threats usually serve to amplify the discussion +of the case within the security community, which draws more attention to +the vendor and its products at the same time it demotivates reporters' +willingness to participate in the CVD process. Even more problematic is +that when such attention comes to focus on the vendors' products, it is +very likely that additional vulnerabilities will be found—while +simultaneously less likely that anyone will bother to report them to the +vendor before disclosing them publicly. + +!!! tip "Beware The Power of Spite" + + Vendors should not underestimate spite as a motivation for vulnerability discovery. + +{% include-markdown "../recipes/_x20.md" heading-offset=1 %} +{% include-markdown "../recipes/_x05.md" heading-offset=1 %} diff --git a/docs/howto/coordination/independent_discovery.md b/docs/howto/coordination/independent_discovery.md new file mode 100644 index 0000000..4a1a7a4 --- /dev/null +++ b/docs/howto/coordination/independent_discovery.md @@ -0,0 +1,92 @@ +# Independent Discovery + +If one person can find a vulnerability, somebody else can, too. +When multiple parties independently discover the same vulnerability, it +can complicate the CVD process. + +!!! example inline end "Research on Independent Discovery" + + Research has shown that vulnerabilities are often independently + discovered. + [Andy Ozment](https://web.archive.org/web/20220718203842id_/http://infosecon.net/workshop/pdf/10.pdf) + showed that "vulnerability rediscovery occurs 'in the + wild' and that it is not particularly uncommon." + [Finifter and colleagues](https://www.usenix.org/conference/usenixsecurity13/technical-sessions/presentation/finifter), + reviewing a dataset of Chrome vulnerabilities, identified 15 + out of 668 (2.25%) that had been independently discovered by multiple + parties. They go on to mention similar rates for Firefox + vulnerabilities. + [Ablon and Bogart](https://www.rand.org/content/dam/rand/pubs/research_reports/RR1700/RR1751/RAND_RR1751.pdf) + studied a stockpile of zero day vulnerabilities, estimating that "after a year approximately 5.7 + percent have been discovered and disclosed by others." + [Herr and Schneier](https://ssrn.com/abstract=2928758) + find browser vulnerabilities having rediscovery rates + between 11% and 20% annually for the years 2013-2015. For Android + vulnerabilities during the 2015-2016 timeframe, they found an annual + rediscovery rate of 22%. + +!!! question "What is to be done when the CVD process is underway for a vulnerability, and a seemingly independent report of the same vulnerability arrives?" + + Options include: + + 1. accelerating public disclosure or + 2. continuing with the CVD process. + +## Accelerate Public Disclosure + +One approach is to accelerate the disclosure timeline, possibly +disclosing immediately. This approach assumes that if a vulnerability +has been found and reported by multiple individuals acting +independently, then it must be an easy vulnerability to find. This in +turn implies that others who haven't reported it may also be aware of +its existence, thereby increasing the likelihood of its availability to +adversaries. + +## Continue with the CVD Process + +While we find this to be a reasonable conclusion, CVD participants +should be wary of duplicate reports that are not independent. Truly +independent discovery does yield some indication of the difficulty of +finding a vulnerability. But vulnerability finders and security +researchers talk to each other, and they sometimes hunt in the same +places. An announcement of interesting vulnerabilities in a product can +spur others to turn their attention and tools to that product. Even a +casual "I've been looking at product X and found some interesting +things" can put someone else on the hunt for vulnerabilities in product +X. Any judgement of independence should consider the degree to which +there is community interest in a product. As the popularity of products +wax and wane through their lifespan, so too will security researcher +attention. + +
+ +!!! example "Heartbleed and Duplicate Reports" + + An example of a coordination failure occurred during the vulnerability + disclosure of Heartbleed. Two organizations, Codenomicon and Google, + both discovered the vulnerability around the same time. When the + vulnerability was reported a second time to the OpenSSL team, the team + assumed a possible leak and the vulnerability was quickly disclosed + publicly ([source](http://www.smh.com.au/it-pro/security-it/heartbleed-disclosure-timeline-who-knew-what-and-when-20140414-zqurk.html)). A more coordinated response may have allowed further + remediation to be available immediately at disclosure time. + +!!! example "Bug Bounties and Duplicate Reports" + + Even more insidious is a phenomenon we've observed in bug bounty + scenarios. Because they pay for reports, bug bounties can + unintentionally provide incentives for finders to share their reports + with others prior to reporting, allowing multiple individuals to report + the same bug, and potentially share in a larger payout. CVD is a social + game: as such, its incentives affect participants' behavior. + +
+ +!!! tip "Consider Options on a Case-by-Case Basis" + + Rather than prescribing a single rule that independent discovery should + immediately trigger release of the vulnerability information, we suggest + that CVD participants discuss the implications of rediscovery on a + case-by-case basis in order to decide the best course of action for the + particular case. + +{% include-markdown "../recipes/_x15.md" heading-offset=1 %} diff --git a/docs/howto/coordination/index.md b/docs/howto/coordination/index.md new file mode 100644 index 0000000..b535790 --- /dev/null +++ b/docs/howto/coordination/index.md @@ -0,0 +1,102 @@ +# Coordinating Vulnerability Disclosure + +Participating in a CVD process can be challenging. +This section provides some advice on how to handle common issues that might arise during the coordination process. + +
+ +- :material-help-network: [Reasons to Engage a Coordinator](./coordinator_reasons.md) + + --- + {% include-markdown "./coordinator_reasons.md" start="" end="" %} + +- :material-stamper: [Validation](./validation.md) + + --- + {% include-markdown "./validation.md" start="" end="" %} + +- :material-sort: [Prioritization](./prioritization.md) + + --- + {% include-markdown "./prioritization.md" start="" end="" %} + +- :fontawesome-solid-people-group: [Multiparty CVD](./mpcvd.md) + + --- + {% include-markdown "./mpcvd.md" start="" end="" %} + +- :material-run-fast: [Response Pacing and Synchronization](./response_pacing.md) + + --- + {% include-markdown "./response_pacing.md" start="" end="" %} + +- :material-phone-hangup: [Somebody Stops Replying](./somebody_stops_replying.md) + + --- + {% include-markdown "./somebody_stops_replying.md" start="" end="" %} + +
+ +## Embargoes in Coordinated Vulnerability Disclosure + +Embargoes are a common tool in the CVD process, but they can be tricky to manage. +This section provides some advice on how to handle embargoes effectively, even when things don't go as planned. + +
+ +- :material-pen-lock: [Maintaining Pre-Disclosure Secrecy](./maintaining_secrecy.md) + + --- + {% include-markdown "./maintaining_secrecy.md" start="" end="" %} + +- :material-timer-outline: [Disclosure Timing](./disclosure_timing.md) + + --- + {% include-markdown "./disclosure_timing.md" start="" end="" %} + +- :material-content-duplicate: [Independent Discovery](./independent_discovery.md) + + --- + {% include-markdown "./independent_discovery.md" start="" end="" %} + +- :material-pipe-leak: [Intentional or Accidental Leaks](./leaks.md) + + --- + {% include-markdown "./leaks.md" start="" end="" %} + +- :material-fire-alert: [Active Exploitation](./active_exploitation.md) + + --- + {% include-markdown "./active_exploitation.md" start="" end="" %} + +
+ +## Complications in Coordinated Vulnerability Disclosure + +Other complications can arise during the CVD process. +This section provides some advice on how to handle these issues effectively. +A summary of the advice in this section, along with a number of other scenarios can be found in [Troubleshooting CVD](./cvd_recipes.md). + +
+ +- :fontawesome-solid-people-pulling: [Relationships that Go Sideways](./relationships_sideways.md) + + --- + {% include-markdown "./relationships_sideways.md" start="" end="" %} + +- :material-bullhorn: [Hype, Marketing, and Unwanted Attention](./hype.md) + + --- + {% include-markdown "./hype.md" start="" end="" %} + +- :material-clipboard-list: [Troubleshooting Coordinated Vulnerability Disclosure](./cvd_recipes.md) + + --- + {% include-markdown "./cvd_recipes.md" start="" end="" %} + +- :material-tooltip-check: [What To Do When Things Go Wrong](./general_tips.md) + + --- + {% include-markdown "./general_tips.md" start="" end="" %} + +
diff --git a/docs/howto/coordination/leaks.md b/docs/howto/coordination/leaks.md new file mode 100644 index 0000000..1f3fd9f --- /dev/null +++ b/docs/howto/coordination/leaks.md @@ -0,0 +1,34 @@ +# Intentional or Accidental Leaks + +Unfortunately, not everyone plays by the same rules.You might find +information you thought was shared in confidence showing up in some +non-confidential location. It might be a simple misunderstanding, +mismatched expectations, or in rare cases, a malicious act. + +!!! example "Ways Information Can Leak" + + Sometimes information leaks out of the CVD process. + + - Perhaps an email gets CC'ed to someone who didn't need to know. + - Somebody might talk too much at a conference. + - Somebody could post that they just found a vulnerability in a product, providing no other details. + - Somebody might intentionally disclose the information to someone not involved in the supply chain for the fix. + +!!! question "Questions to Ask When Information Leaks" + + Regardless of how it leaked, there are three major questions to ask: + + 1. What information leaked? + 2. How did the information leak? + 3. How will you respond? + +!!! warning "Even Partial Leaks Can Be Serious" + + As we note in [Disclosure Timing](../../howto/coordination/disclosure_timing.md), mere + knowledge that a vulnerability exists in a certain component can + sometimes be enough to enable a determined individual or organization to + find it. While a partial leak of information isn't necessarily as + serious as a detailed leak, it should at least trigger additional + consideration of accelerating the disclosure timeline. + +{% include-markdown "../recipes/_x11.md" heading-offset=1 %} diff --git a/docs/howto/coordination/maintaining_secrecy.md b/docs/howto/coordination/maintaining_secrecy.md new file mode 100644 index 0000000..64c23e9 --- /dev/null +++ b/docs/howto/coordination/maintaining_secrecy.md @@ -0,0 +1,83 @@ +# Maintaining Pre-Disclosure Secrecy + +[Multiparty disclosure](mpcvd.md) highlights the need to balance need-to-know with need-to-share. +The more parties involved in a case, and the longer the embargo period +lasts, the more likely a leak becomes. + +!!! question "Who Needs to Know What, When?" + + There are varying degrees of need-to-know. + Not everyone needs to know the same thing at the same time. + Patch originators are usually notified early in the process, since their answer to + "What do I need to do in response to this knowledge?" (i.e., create a patch) + is often on the critical path for any downstream parties to be able to take action. + Downstream vendors (patch consumers) and deployers can be notified later. + +## The Risk of Leaks + +Keeping secrets over time is hard. +[The more people who know a secret, the more likely it is to leak.](https://doi.org/10.1371/journal.pone.0147905) +Simple probability theory tells us that even if the probability of any +given party leaking is very low, the cumulative probability of a leak +increases exponentially with the number of parties involved. + +!!! example "Larger Cases Face Increased Leak Risk" + + While it's hard to measure the actual probability of a leak in a given case, + it's clear that the more parties involved, the more likely a leak becomes. + For example, let's say that the probability of any given party leaking during + a given case is $1$ in $1000$. + If there are $10$ parties involved, the probability that + none of them leak is $0.999^{10}$, or about 99%. + If there are $100$ parties involved, the probability that none of them leak is only + $0.999^{100}$, or about 90%. + But if there are $1000$ parties involved, the probability that none of them leak is only $0.999^{1000}$, + or about 37%, meaning that the probability that at least one of them leaks is about 63%. + + Lest you think that $1000$ participants in a case is an unrealistic number, consider that + in the Apache Log4j case [VU#930724](https://kb.cert.org/vuls/id/930724) + ([CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), + [CVE-2021-4104](https://nvd.nist.gov/vuln/detail/CVE-2021-4104), + [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046), + the CERT/CC notified $1643$ vendors, and we're reasonably certain that we missed more than a few. + +!!! tip "Keep Embargoes Short" + + Controlling the number of participants involved in a case is one way to reduce the risk of a leak. + But if we want to reach all the vendors with affected products, we often can't avoid involving many parties. + And every vendor involved is likely to have multiple people involved in the case. + So even in a case with only a few vendors, the number of individuals involved can quickly grow into the hundreds. + Furthermore, the broader the audience for an embargoed disclosure, the more likely that it will involve + parties who are not used to handling embargoed information, or who have different values or priorities, + leading to a higher risk of a leak. + + A more reliable way to reduce the risk of a leak is to keep the embargo period as short as possible. + The longer the embargo, the more likely a leak becomes, regardless of the number of parties involved. + That doesn't mean you should rush the process (because that can lead to other problems including loss of + trust due to incomplet or incorrect patches), but it does mean you should beware the risks of a long embargo. + +## Coordinating Further Downstream + +Vulnerabilities having the potential for significant impact can lead to +coordination efforts beyond the traditional product vendor space. + +!!! question "Do You Include Deployers?" + + Infrastructure and service providers are sometimes brought in early, if + there are mitigations that can be deployed in advance of the + availability of a fix. This can be especially helpful in cases where the + vulnerability may affect the infrastructure necessary to distribute the + patch in the first place. + + Be careful to consider fairness though: By what criteria should you + notify _service provider X_ but not _service provider Y_? At some point, the + complexity of who knows what gets high enough that the likelihood of a + leak goes to 1, and you might as well go public. + +!!! warning "Complex Communications Reduce Trust" + + It's also important to be aware that not all participants along the + chain of disclosure will be equally trustworthy. That's not to say they + are actively malicious, just that they may have incompatible values or + priorities that lead them to disclose the existence of the vulnerability + to others earlier than you'd prefer. diff --git a/docs/howto/coordination/mpcvd.md b/docs/howto/coordination/mpcvd.md new file mode 100644 index 0000000..1ca0263 --- /dev/null +++ b/docs/howto/coordination/mpcvd.md @@ -0,0 +1,308 @@ +# Multiparty CVD + +The simplest instance of CVD is when there are only two parties +involved: the finder of the vulnerability and the vendor who can fix the +software. In this case, many of the complexities that arise in +multiparty situations do not come into play. + +!!! tip inline end "Two-Party CVD is Not Always Easy" + + None of this is to say that two-party CVD is always straightforward or easy. + It can still be difficult for the finder of a vulnerability to make + contact with the vendor. It can sometimes be difficult for the vendor to + work with the finder toward a resolution. + + Personalities, attitudes, expectations, assumptions, and egos all play a + part in the success or failure of even two-party CVD. + +Most of the interesting cases in CVD involve more than two parties, as +these are the cases where the most care must be taken. Automation of the +process can help somewhat, but the impact technology can have on the +problem is limited by the inherent complexities involved in trying to +get numerous organizations to synchronize their development, testing, +and release processes in order to reduce the risk to users. + +From a coordinator's perspective, it can be difficult to be fair, as +you're almost guaranteed to either miss some downstream vendor or wind +up with one or more vendors ready to release while everyone is waiting +for the other vendors to catch up. We discuss this conundrum further in +[Troubleshooting CVD](./cvd_recipes.md). + +
+ +!!! info inline end "FIRST MPCVD Guidelines and Practices" + + The FIRST [Vulnerability Coordination SIG](https://www.first.org/global/sigs/vulnerability-coordination/) + has published its + [_Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure_](https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1) + which we strongly recommend reading. + + Summarizing their guiding concepts and best practices: + + - Establish a strong foundation of processes and relationships + - Maintain clear and consistent communications + - Build and maintain trust + - Minimize exposure for stakeholders + - Respond quickly to early disclosure + - Use coordinators when appropriate + +!!! tip "Multiparty CVD is About People" + + Success at multiparty coordination has more to do with understanding + human communication and organization phenomena than with the technical + details of the vulnerability. The hard parts are nearly always about + coordinating the behavior of multiple humans with diverse values, + motives, constraints, beliefs, feelings, and available energy and time. + The vulnerability details may dictate the "what" of the response, but + to a large degree human social behaviors decide the + "how." + +In the next few subsections we discuss a number of issues that we have +observed in performing multiparty CVD over the +years. + +## Multiple Finders / Reporters + +If one person can find a vulnerability, another person can too. While +documented instances of independent discovery are relatively rare, +independent discovery of vulnerabilities can and does happen. + +
+!!! example "Heartbleed and Multiple Finders" + + Perhaps the best known example of multiple finders is [Heartbleed](http://heartbleed.com/) + ([CVE-2014-0160](https://nvd.nist.gov/vuln/detail/cve-2014-0160)). + In part because of the complexity of the coordinated disclosure + process, a second CVE identifier ([CVE-2014-0346](https://nvd.nist.gov/vuln/detail/CVE-2014-0346)) + was assigned to the same vulnerability and later retracted. + +!!! tip "Independent Discovery" + + Independent discovery is a phenomenon where two or more parties + discover the same vulnerability without any of the parties being aware + of the others' work. Independent discovery can be a significant + complicating factor in CVD, as it can lead to multiple reports of the + same vulnerability, which can in turn lead to confusion, duplication of + effort, and even conflict among the parties involved. + We discuss this topic further in [Independent Discovery](./independent_discovery.md). + +## Complicated Supply Chains + +Many products today are not developed by a single organization. +Instead, they are assembled from components sourced from other +organizations. Vulnerabilities in these components can have far-reaching +impacts and require coordination among multiple parties to resolve. + +For example, software libraries are often licensed for inclusion into +other products. When a vulnerability is discovered in a library +component, it is very likely that not only does the originating vendor +of the library component need to take action, but all the downstream +vendors whose products use it need to take action as well. Complex +supply chains can increase confusion regarding who is responsible for +coordinating, communicating, and ultimately fixing vulnerabilities, +leading to delays and systems exposed to unnecessary +risk. + +{% include-markdown "../../_includes/_mobile_supply_chain.md" heading-offset=1 %} + +At the CERT/CC, we often find it useful to distinguish between vertical +and horizontal supply chains. While the vertical supply chain is more +common, we do occasionally need to navigate horizontal supply chains in +the course of the CVD +process. + +### Vertical Supply Chain + +In a vertical supply chain, a vulnerability exists in multiple products +because they all share a dependency on a vulnerable library or +component. One vendor originates the fix. Many vendors then have to +incorporate the originating vendor's fix into their products. Many +vendors have to publish documents, distribute patches, and cause +deployers to take +action. + +```mermaid +--- +title: Vertical Supply Chain - Single Originator +--- +flowchart TD + F[Reporter] + V1[Originating
Vendor] + V2[Downstream
Vendor] + V3[Downstream
Vendor] + V4[Downstream
Vendor] + V5[Downstream
Vendor] + D1[Deployer] + D2[Deployer] + F -->|Reports to| V1 + V1 -->|Develops Fix| V1 + V1 -->|Distributes Fix| V2 + V1 -->|Distributes Fix| V3 + V2 -->|Integrates Fix| V2 + V3 -->|Integrates Fix| V3 + V2 -->|Distributes Fix| V4 + V3 -->|Distributes Fix| V5 + V4 -->|Integrates Fix| V4 + V5 -->|Integrates Fix| V5 + V4 -->|Notifies| D1 + V5 -->|Notifies| D2 + +``` + +!!! example "CVD in a Vertical Supply Chain" + + One example of a CVD process following a vertical supply chain is as + follows: a vulnerability might be initially identified in product X, but + is then isolated to a library that product X includes as a dependency. + In this case, the library developer must be engaged as another party to + the coordination process in the role of patch originator. + + The complexity does not end there though. Once the library vendor has + completed its patch, not only does the vendor of product X have to + integrate the fix, but all the other vendors that include the library + need to update their products as well. We have done this kind of + coordination in the past with vulnerabilities affecting MS-SQL ([VU#484891](https://www.kb.cert.org/vuls/id/484891)), + Oracle Outside In ([VU#916896](https://www.kb.cert.org/vuls/id/916896)), and so on. + The cascading effects of library + vulnerabilities often result in significant subsets of users left + vulnerable while they await their product vendor's + updates. + + ```mermaid + --- + title: Vertical Supply Chain with Library Component + --- + flowchart TD + F[Reporter] + V2[Vendor] + VC[Library
Distrubution
Channel] + F -->|1. Reports to| V2 + V1[Library
Vendor] + V2 -->|2. Reports to| V1 + V1 -->|3. Develops Fix| V1 + V1 -->|4. Distributes Fix| VC + V3[Vendor] + V4[Vendor] + V5[Vendor] + VC --> V2 + VC --> V3 + VC --> V4 + VC --> V5 + P[Public] + V2 -->|5. Integrates Fix| V2 + V3 -->|5. Integrates Fix| V3 + V4 -->|5. Integrates Fix| V4 + V5 -->|5. Integrates Fix| V5 + V1 -->|6. Notifies| P + V2 -->|6. Notifies| P + V3 -->|6. Notifies| P + V4 -->|6. Notifies| P + V5 -->|6. Notifies| P + ``` + +### Horizontal Supply Chain + +Even more complex in terms of coordination are cases where multiple +products implement the same vulnerability, which is the primary +characteristic of a horizontal supply chain. Examples include +vulnerabilities arising from underspecified protocols, design flaws, and +the like. Luckily these kinds of vulnerabilities are rare. + +CVD can become quite complicated when they occur, because multiple +vendors must originate fixes for their own implementations. Many such +cases combine with each originating vendor's downstream vertical supply +chain as well, which only serves to increase the complexity. Many +vendors have to publish docs and distribute patches, leading to +deployers needing to take multiple actions. + +Multiple implementation vulnerabilities can sometimes result from +widespread copying of vulnerable code examples from books or websites or +from developer tutorials that ignore or intentionally disable security +features in order to simplify the learning process. + +```mermaid +--- +title: Horizontal Supply Chain - Multiple Originators +--- +flowchart TD + F[Reporter] + V1[Originating
Vendor] + V2[Originating
Vendor] + V3[Originating
Vendor] + V4[Originating
Vendor] + V4SC[[Vertical
Supply Chain]] + D1[Deployer] + D2[Deployer] + D3[Deployer] + D4[Deployer] + F -->|Reports to| V1 + F -->|Reports to| V2 + F -->|Reports to| V3 + F -->|Reports to| V4 + V1 -->|Develops Fix| V1 + V2 -->|Develops Fix| V2 + V3 -->|Develops Fix| V3 + V4 -->|Develops Fix| V4 + V1 -->|Notifies| D1 + V2 -->|Notifies| D2 + V3 -->|Notifies| D3 + V4 -->|Notifies| D4 + V4 -.->|Distributes Fix| V4SC + V4SC -.->|Integrates Fix| V4SC + V4SC -.->|Notifies| D4 +``` + +!!! example "Android SSL MitM as a Multiple Implementation Vulnerability" + + While we cannot + place the entirety of the blame for widespread Android SSL + Man-in-the-Middle vulnerabilities like [VU#582497](https://www.kb.cert.org/vuls/id/582497) on any + specific phenomenon, our spot checks of some of the vulnerable apps made + it clear that parallel implementation of the same errors was a + contributing factor in many of the affected apps. + In that case, we identified more than + [23,000 distinct apps](https://docs.google.com/spreadsheets/d/1t5GXwjw82SyunALVJb2w0zi3FoLRIkfGPc7AMjRF0r4), + and coordinated with thousands of vendors. + +!!! example "Protocol Vulnerabilities" + + A more pernicious example of multiple implementation is a vulnerability + whose root cause lies in the specification or reference implementation + of a network protocol. Because most vendor's products will specifically + test for compatibility with these reference artifacts, such cases + usually imply that every product supporting that feature will need to be + fixed. Multi-originator cases can be very complex to coordinate. The + SNMP vulnerabilities found in 2002 via the [OUSPG PROTOS Test Suite + c06-snmpv1](https://web.archive.org/web/20140901000000*/https://www.ee.oulu.fi/research/ouspg/PROTOS_Test-Suite_c06-snmpv1) + ([VU#854306](https://www.kb.cert.org/vuls/id/854306), + [VU#107186](https://www.kb.cert.org/vuls/id/107186), + [CA-2002-03](https://insights.sei.cmu.edu/library/2002-cert-advisories/)) + represented just such a case, and remain to + this day among the most complex disclosure cases the CERT/CC has ever + coordinated. + +!!! info "Mass Notifications for Multiparty CVD" + + In their Usenix Security 2016 paper + [_Hey, You Have a Problem: On the Feasibility of Large-Scale Web Vulnerability Notification_](https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/stock), + Ben Stock, Giancarlo Pellegrino, and Christian Rossow examined issues surrounding large-scale vulnerability notification + campaigns. + In this work, which focused on notifying website operators of vulnerabilities in their sites, + they highlight significant difficulty in establishing a direct communication channel with vulnerable sites. + + The following is from their conclusion: + + !!! quote "Stock, Pellegrino, and Rossow on Large-Scale Notifications" + + How do we inform affected parties about vulnerabilities on large + scale? Identifying contact points remains the main challenge that has to + be addressed by the Internet society, including network providers, + CERTs, and registrars. We imagine that this problem could, for example, + be tackled by centralized contact databases, more efficient + dissemination strategies within hosters/CERTs, or even a new + notification channel or trusted party responsible for such + notifications. Until we find solutions to the reachability problem, the + effects of large-scale notifications are likely to remain low in the + future. + +{% include-markdown "../../_includes/_report_certcc.md" heading-offset=1 %} diff --git a/docs/howto/coordination/prioritization.md b/docs/howto/coordination/prioritization.md new file mode 100644 index 0000000..1a9518c --- /dev/null +++ b/docs/howto/coordination/prioritization.md @@ -0,0 +1,64 @@ +# Prioritization Heuristics + +Even for the reports a vendor accepts as [valid](validation.md) (in scope, credible, and valid), +it is likely that the development team does not have time to address every +report at the moment it arrives. Thus, if a report is found to be valid, +the next question is how to allocate resources to the report. Most often +this requires some measure of how significant the vulnerability is compared +to other vulnerabilities that have been reported. In some +scenarios, the vulnerability may be a critical flaw that requires +immediate action, while other cases might indicate a very rare and +hard-to-exploit vulnerability that should be given a low priority. + +!!! note inline end "Beware Misuse of Scoring Systems" + + In our 2021 article [_Time to Change the CVSS?_](https://doi.org/10.1109/MSEC.2020.3044475), we + argued that many organizations misuse the Common Vulnerability Scoring System (CVSS) + by using it as a risk metric, when it was never intended to be used that way. + Since that time, [CVSS version 4.0](https://www.first.org/cvss/v4.0/specification-document) has been released, + and while it is a significant improvement over previous versions, it still has limitations. + We have generally found that the information contained in the CVSS _vector_ is more useful than the _score_ itself. + This led us to develop the [Stakeholder-Specific Vulnerability Categorization](https://certcc.github.io/SSVC) (SSVC) as a more flexible alternative. + +There are a number of heuristics for evaluating the severity of +vulnerabilities. Perhaps the most commonly known of these is the [Common +Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS). This system allows a short +standard description of the impact of a vulnerability and can be mapped +to a score between 1.0 and 10.0 to help prioritization. + +The [Common Weakness Scoring System](https://cwe.mitre.org/cwss/cwss_v1.0.1.html) (CWSS) +is a similar system that was intended to be used to assess the potential impact of a class of +weaknesses. +Whereas CVSS addresses the detailed impact of a specific vulnerability, +CWSS could be used to evaluate the impact of a class of weaknesses. + +While scoring systems like CVSS and CWSS can be useful at establishing +relative severity among reports, care must be taken in their use since +scores do not always map well onto a vendor's or deployer's +priorities. + +
+ +!!! ssvc "Stakeholder-Specific Vulnerability Categorization (SSVC)" + + The CERT/CC's [Stakeholder-Specific Vulnerability Categorization](https://certcc.github.io/SSVC) (SSVC) + provides a method for developing vulnerability management decision models + that are tailored to the specific needs of different stakeholders. + +!!! tip "Heuristic Evaluation" + + Vendors, Coordinators, and Deployers should ensure their analysts are trained + in the chosen heuristic + and understand its strengths and weaknesses so that its result can be + overridden when necessary. + + We do not, for example, recommend blind + adherence to hard cutoffs such as "We only bother with reports that + have a CVSS score greater than 7.0." No vulnerability scoring system is + so precise. + + Ideally, whatever prioritization scheme is used should also + be made transparent to reporters so that the process is understood by + all stakeholders. Transparency in this part of the process can help + prevent frustration and confusion when CVD participants disagree on + the priority given to a vulnerability. diff --git a/docs/howto/coordination/relationships_sideways.md b/docs/howto/coordination/relationships_sideways.md new file mode 100644 index 0000000..82083da --- /dev/null +++ b/docs/howto/coordination/relationships_sideways.md @@ -0,0 +1,27 @@ +# Relationships that Go Sideways + +CVD is a human coordination process, and humans are complicated. +They have feelings, and those feelings can get hurt. +People get frustrated, angry, and sometimes just have bad days. +And sometimes, they just don't get along. + +When relationships go sideways in a CVD process, it can be a real problem. +The process can stall, or worse, the vulnerability can be disclosed in a way that is harmful to users. + +!!! tip "The Human Element" + + The first thing to do when things appear to be going awry in a CVD case + is to give people some slack to make mistakes. + +!!! tip "Transparency, Consistency, and Simplicity" + + The more transparent your process is—and the closer it is to what + other folks are doing—the better you will be able to avoid problems. + + Transparency is a key element of a successful CVD process. + Good documentation is a start, but documenting a byzantine process + isn't as useful as simplifying the process and then documenting that! + +{% include-markdown "../recipes/_x21.md" heading-offset=1 %} + +{% include-markdown "../../_includes/_report_certcc.md" heading-offset=1 %} diff --git a/docs/howto/coordination/response_pacing.md b/docs/howto/coordination/response_pacing.md new file mode 100644 index 0000000..83dd6e5 --- /dev/null +++ b/docs/howto/coordination/response_pacing.md @@ -0,0 +1,106 @@ +# Response Pacing and Synchronization + +Problems can arise when the multiple parties involved in CVD function at +different operational tempos. Different organizations have different +priorities and development schedules, which can lead to some parties +wanting to move faster than others. + +In both the vertical and horizontal supply +chain cases discussed in [Multiparty CVD](mpcvd.md), synchronized timing of disclosure to the +public can be difficult to coordinate. The originating vendor(s) will +usually want to release a patch announcement to the public as soon as it +is ready. This can, however, put users of downstream products at +increased risk. As a result, coordinators sometimes find it necessary to +make the difficult choice to withhold notification from a vendor in a +complicated multiparty disclosure case if that vendor cannot be trusted +to cooperate with the coordination effort. + +!!! tip "When One Party Wants to Release Early" + + In a multiparty coordination scenario, some vendors may want to release + early to protect their customers. They have a good point: should _Vendor + A_'s customers be kept vulnerable just because _Vendor B_ is taking longer + to prepare its response? Yet an equally strong counterargument can be + made: should customers of _Vendor B_ be exposed to additional risk because + _Vendor A_ was faster at its vulnerability response process? + + ```mermaid + stateDiagram-v2 + direction LR + notify: Notify
Vendors + State2: Vendor A
Fix Development + State5: Vendor A
Ready + State3: Vendor B
Fix Development + State6: Vendor B
Ready + State4: Public
Disclosure + state fork_state <> + [*] --> notify + notify --> fork_state + fork_state --> State2 + fork_state --> State3 + State2 --> State5 + State3 --> State6 + state join_state <> + State5 --> join_state + State6 --> join_state + join_state --> State4 + State4 --> [*] + ``` + + There is no + single right answer to this dilemma. The best you can do is keep the + communication channels open and try to reduce the amount of surprise + among participants. Planning for contingencies can be a useful exercise + too—the focus of such a contingency should be how to respond if + information about the vulnerability got out before you were ready for + it. + +## Motivating Cooperation Across Cases + +CVD process discussions tend to focus on the handling of individual +vulnerability cases rather than the social fabric surrounding +vulnerability coordination we construct over time. Shifting away from +the individual units of work to the social structure can suggest a way +out of some of the more contentious points in any given case. + +!!! info inline end "Axelrod's Principles on the Evolution of Cooperation" + + Robert Axelrod's book _The Evolution of Cooperation_ is a classic + text on the topic. Axelrod's [work](https://ee.stanford.edu/~hellman/Breakthrough/book/pdfs/axelrod.pdf) + showed that the most successful strategies in repeated games follow certain principles, which we + include here for reference: + + - Don’t be envious + - Don’t be the first to defect + - Reciprocate both cooperation and defection + - Don’t be too clever + +We previously described the multiparty delay problem. Game theory +provides us with the prisoners' dilemma as model for thinking about +this concern. The main takeaway from research into the prisoners' +dilemma is that by shifting one's perspective to considering a repeated +game, it's possible to find better solutions than would be possible in +a one-shot game with no history. The recognition that it's a repeated +game leads to improved cooperation among players who would otherwise be +motivated to act solely in their own self-interest in each round. + +One approach we've found to work is to remind the parties involved that +this will likely not be the last multiparty vulnerability coordination +effort in which they find themselves. A vendor that repeatedly releases +early will likely get left out of future coordination efforts. Because +of this, the quicker vendors might be motivated to delay so they get the +vulnerability information the next time. + +!!! tip "The Repeated Game" + + Perhaps most important for + those wanting to release early is to remember that this is a repeated + game; you might be first one ready to publish this time but that may not + always be the case. Consideration for the other parties involved in any + given case can yield better outcomes in the long run. + +In the end, everyone benefits from vendors improving their vulnerability +response processes, so helping the laggards become more efficient can +sometimes become a secondary goal of the coordination process. + +{% include-markdown "../../_includes/_report_certcc.md" heading-offset=1 %} diff --git a/docs/howto/coordination/somebody_stops_replying.md b/docs/howto/coordination/somebody_stops_replying.md new file mode 100644 index 0000000..965618f --- /dev/null +++ b/docs/howto/coordination/somebody_stops_replying.md @@ -0,0 +1,32 @@ +# Somebody Stops Replying + +Sometimes one of the parties involved in a CVD effort will stop +responding. Often, this is simply a reflection of priorities and +attention shifting elsewhere rather than intentional behavior. It's +usually best to give the benefit of the doubt and keep trying to +reestablish contact if one of the CVD participants goes unresponsive. +Even in cases where the vendor has stopped responding in the midst of a +coordination effort, the CERT/CC recommends that reporters send the +vendor a "heads up" message with some lead time before publishing, +optionally including a draft of the document about to be published. This +helps the vendor prepare its communication plan if necessary, and +sometimes helps to identify any lingering misunderstandings on the +technical aspects of the vulnerability. + +!!! example "Example: A 2015 Minecraft Vulnerability" + + Ammar Askar's [blog post](http://blog.ammaraskar.com/minecraft-vulnerability-advisory/) + about a Minecraft vulnerability serves as an example where a quick heads up to + the vendor could have avoided some confusion. + + > Update 2: The exact problem that caused this bug to go unpatched has been identified. + > Mojang attempted to implement a fix for this problem, however they did not test their fix against the proof of + > concept I provided, which still crashed the server perfectly fine. This, in combination with ignoring me when I + > asked for status updates twice led me to believe that Mojang had attempted no fix. In retrospect, a final warning + > before this full disclosure more recently was propbably in order. A combination of mis-communication and lack of + > testing led to this situation today, hopefully it can be a good learning experience. + +{% include-markdown "../recipes/_x06.md" heading-offset=1 %} +{% include-markdown "../recipes/_x10.md" heading-offset=1 %} + +{% include-markdown "../../_includes/_report_certcc.md" heading-offset=1 %} diff --git a/docs/howto/coordination/validation.md b/docs/howto/coordination/validation.md new file mode 100644 index 0000000..0775634 --- /dev/null +++ b/docs/howto/coordination/validation.md @@ -0,0 +1,110 @@ +# Validating Reports + +When a [vendor](../../topics/roles/vendor.md) or [coordinator](../../topics/roles/coordinator.md) +receives a vulnerability report, it's usually necessary to prioritize it along with other +vulnerability reports already in progress, new feature development, and possibly other non-security bug fixes. +As a result, there are a few considerations to be made in dealing with incoming reports. +These essentially boil down to three questions: + +!!! question "Questions to Consider" + + 1. Is the report in scope? + 2. Is the report credible and valid? + 3. What priority should the report be given? + + We tackle the first two questions in this section, and the third in the [next section](prioritization.md). + +## Scope + +A CVD participant's scope determines which cases they can and should handle. +A vendor's scope is usually the set of their products, along with any components their products depend on. + +!!! tip "End-of-Life Software and Scope" + + For many vendors, End-of-Life (EoL) software might be out of scope by default, but sometimes it is worth considering as in-scope. + For example, vendors may choose to provide fixes for vulnerabilties in EoL software if the software only recently went out of support and the vulnerability has a severe impact. + +!!! example "Scope for a Coordinating CSIRT" + + A coordinator also has a scope defined by their specific constituency and mission. + For example, a CSIRT within a government agency might have a scope limited to systems operated by that agency. + Other government CSIRTs might have responsibility for systems across the entire government. + Some ISAOs have a scope to cover vulnerabilities in a specific infrastructure sector or industry. + +Regardless what a CVD participant's scope is, it is usually easiest to determine whether a received report meets their +scope criteria before proceeding to validate the report. +If a report arrives and would be out of scope *even if* true, there will be no need to proceed with judging its credibility. +CVD participants should decide what to do about out of scope reports separately, before the vulnerability coordination +validation and prioritization decisions begin. + +!!! tip "Handing off Out-of-Scope Reports" + + A judgement that a report is out of scope need not result in simply dropping the case. + The case might be handed off to a more appropriate vendor or coordinator for whom it would be in scope, for example. + +## Recognizing High-Quality Reports + +Not all reports are actionable. Some reports may under-specify the +problem, making it difficult or impossible to reproduce. Some may +contain irrelevant details. Some will be well written and concise, but +many will not. Some reports could describe problems that are already +known or for which a fix is already in the pipeline. + +In easy cases, a simple description of the vulnerability, a screenshot, +or a copy/pasted snippet of code is all that is necessary to validate +that a report is likely accurate. In more complex scenarios, stronger +evidence and/or more effort might be required to confirm the +vulnerability. Responsive vendors should ensure analysts have access to +appropriate resources to test and validate bugs, such as virtual +machines (VMs), a testing network, and debuggers. + +{% include-markdown "./_report_credibility.md" heading-offset=2 %} + +## Addressing Validation Problems + +Not all reports you receive will be immediately actionable. Some reports +may be vague, ambiguous, or otherwise difficult to validate. Here are +a few tips for dealing with such reports: + +
+ +!!! tip "Consider Reporter Reputation" + + It may be that reproducing the vulnerability is beyond the capability or + time available by the first-tier recipient at the vendor or coordinator. Most often + this occurs when the conditions required to exploit the vulnerability + are difficult to reproduce in a test environment. In this case, the + triager can weigh the reputation of the reporter against the claims + being made in the report and the impact if they were to be true. You + don't want to dismiss a report of a serious vulnerability just because + it is unexpected. A reporter with a high reputation might give weight to + an otherwise low-quality report (although in our experience finders and + reporters with a high reputation tend to have earned that reputation by + submitting high-quality reports). + +!!! warning "Be cautious of low-quality reports" + + The possibility also exists that someone could be sending you reports to + waste your time, or erroneously believes the report is much more serious + than your analysis suggests. Not all reports you receive warrant your + attention. It is usually reasonable to decline reports if you provide + the reporter with a summary of your analysis and the ability to appeal + (presumably by providing the needed clarifying information). + +!!! tip "Follow up promptly with the reporter" + + If, as the recipient of a report, you encounter difficulty in reproducing the vulnerability, follow + up with the reporter promptly and courteously; be sure to be specific about what you tried + so that the reporter can provide effective advice. In such cases, the receiver might place the + report in a wait state while additional information is requested from the reporter. + +!!! tip "Advice for Reporters" + + Reporters should review [Reporting](../../topics/phases/reporting.md) to + ensure the report contains enough details for the recipient to verify + and reproduce a vulnerability. Be as specific as you can. Vendors that + follow up with questions are doing the right thing, and attempting to + validate your report; be friendly and courteous and attempt to provide + as much detail and help as you can. + +
diff --git a/docs/howto/index.md b/docs/howto/index.md new file mode 100644 index 0000000..77585bd --- /dev/null +++ b/docs/howto/index.md @@ -0,0 +1,21 @@ +# How to Coordinate Vulnerability Disclosures + +This section provides guidance for folks who are actively engaged in Coordinated Vulnerability Disclosure (CVD) +and are looking for advice on how to handle specific situations. +We have organized it roughly in the order that you might encounter these problems, +although we're not strictly adhering to the [Phases](../topics/phases/index.md) we've outlined in the [Understanding CVD](../topics/index.md) section. + +!!! note "How to Use This Section" + + Each page is intended to be a standalone resource, allowing you to directly access the advice you need. + This means that some of the advice may be repeated across pages, but we try to cross-reference where possible. + + The navigation on the left side of the page is organized by topic, consistent with the structure of this page. + Where necessary, navigation within each page is also provided in the right-hand column. + You can use the navigation buttons at the bottom of the page to move through the advice in sequence. + +{% include-markdown "./recipes/_recipe_explainer.md" heading-offset=1 %} +{% include-markdown "./preparation/index.md" heading-offset=1 %} +{% include-markdown "./initiation/index.md" heading-offset=1 %} +{% include-markdown "./coordination/index.md" heading-offset=1 %} +{% include-markdown "./operation/index.md" heading-offset=1 %} diff --git a/docs/howto/initiation/find_vendor_contact.md b/docs/howto/initiation/find_vendor_contact.md new file mode 100644 index 0000000..d67cacb --- /dev/null +++ b/docs/howto/initiation/find_vendor_contact.md @@ -0,0 +1,123 @@ +# Finding Vendor Contacts + +!!! example inline end "How Things Get Complicated" + + Any number of factors can lead to difficulty in making the initial + connection between a would-be reporter and the party or parties that can + do something about the vulnerability they want to report. + + - Sometimes products outlive vendors. This can even happen in open source projects + where the code is still out there but the team that built it has + scattered to the winds. + - Companies go bankrupt. + - People change jobs. + - Maybe Vendor A included a library from Vendor B, who licensed it from C, but + they only got a binary executable and didn't get the source code; and + Vendor C is a spinoff of a conglomerate going through bankruptcy + proceedings in a different country where they don't speak your + language. + +Making initial contact with a vendor can sometimes be more difficult +than it should be. +Here is a list of techniques we've used to figure +out how to reach a vendor we've never spoken with before. + +## Common Methods + +!!! tip "Search the web or the vendor's web site for relevant phrases" + + - "report a vulnerability" + - "security" + - "report a bug" + - "bug bounty" + - "vulnerability disclosure policy" + - "security@" + company name + - company name + "PSIRT" + +!!! tip "Search for a `security.txt` file" + + See if the vendor has a `security.txt` file, often found at + `www.example.com/.well_known/security.txt` or sometimes + at `www.example.com/security.txt` + ([securitytxt.org](https://securitytxt.org/) , [IETF + Draft](https://tools.ietf.org/html/draft-foudil-securitytxt-09)) + +!!! tip "Check the following sources" + + - Vulnerability disclosure / bug bounty service providers + ([BugCrowd](https://www.bugcrowd.com/), [Synack](https://www.synack.com/), [HackerOne](https://www.hackerone.com/), etc.) + - The Forum of Incident Response and Security Teams (FIRST) [member directory](https://www.first.org/members/teams/) + - The [CVE Partner List](https://www.cve.org/PartnerInformation/ListofPartners) + +!!! warning "Avoid posting vulnerability details in public" + + We recommend you avoid posting vulnerability details in public + when making initial contact when possible. For example, + reporters might instead post an issue to a public bug tracker + requesting that the vendor provide a secure method of + communication instead of just posting the vulnerability details + directly in a publicly visible issue. + +!!! tip "Search open source code repositories to find developer contacts" + + - [Github](https://www.github.com/) + - [GitLab](https://gitlab.com/) + - [SourceForge](https://sourceforge.net/) + + - If no direct contact information can be found, posting to the + Issues page of a project asking how they'd like to receive + vulnerability reports can be useful. + +!!! tip "Submit a bug report through the vendor's online bug tracker" + + If given the option to mark it as security-related, please do so as this often restricts viewing to just the vendor. + +!!! tip "Reach out through social media" + + Social media can occasionally be a useful way to make initial contact with a vendor when other methods fail. + + - [Twitter](https://twitter.com/) + - [LinkedIn](https://www.linkedin.com/) + +!!! tip "Try emailing commonly used addresses" + + Sending an email to commonly used addresses can sometimes be useful. + + - `support@` + - `security@` + - `abuse@` + - `info@` + - `sales@` + +!!! tip "Use the vendor's contact form" + + Many vendors have a "Contact Us" form on their web site that can be used to make initial contact. + +!!! tip "Make a phone call to the vendor" + + Sometimes the best way to reach a vendor is to make a phone call. + +!!! tip "Less common, but occasionally useful" + + We have rarely had to resort to these techniques, but they have been + occasionally useful. + + - Send a fax (yes, we've actually done this in the 21st century) + - Send [snail mail](https://insights.sei.cmu.edu/blog/reach-out-and-mail-someone/) to an executive + + - If you have access to resources like [LexisNexis](https://www.lexisnexis.com/), you can often find the names of executives in technical + roles as a starting point. + - If message delivery confirmation is desired, in the US you can send [certified mail](https://faq.usps.com/s/article/Certified-Mail-The-Basics) with signature verification. + The recipient must sign to receive the mail, and you'll get a signed receipt back. + +## When all that fails + +Some vendors remain unreachable even after a number of reasonable good faith attempts to reach them—and by +reasonable we mean considerably less than exhausting the entire list above. +Some vendors just do not seem to want to be reached, and that is their prerogative. +However, we have found that experience is often the best teacher. +When a vendor gets surprised by the publication of a vulnerability in their product and it is clear from the report +that attempts to notify them were made but failed, it can prompt the vendor to re-evaluate their vulnerability +intake and handling processes to make it easier to reach them in the future. + +{% include-markdown "../recipes/_x03.md" heading-offset=1 %} diff --git a/docs/howto/initiation/index.md b/docs/howto/initiation/index.md new file mode 100644 index 0000000..9eea682 --- /dev/null +++ b/docs/howto/initiation/index.md @@ -0,0 +1,30 @@ +# Initiating a Coordinated Vulnerability Disclosure Case + +Sometimes, the hardest part of CVD is getting started. +You might know about a vulnerability, but not know how to reach the vendor. +Or you might be having trouble getting the vendor to respond. +This section provides some advice on how to get the ball rolling. + +
+ +- :material-comment-alert: [Providing Useful Reports](./useful_reports.md) + + --- + {% include-markdown "./useful_reports.md" start="" end="" %} + +- :material-rolodex: [Finding Vendor Contacts](./find_vendor_contact.md) + + --- + {% include-markdown "./find_vendor_contact.md" start="" end="" %} + +- :material-ghost: [Unresponsive Vendor](./unresponsive_vendor.md) + + --- + {% include-markdown "./unresponsive_vendor.md" start="" end="" %} + +- :material-slope-downhill: [Reduce Reporting Friction](./reduce_reporting_friction.md) + + --- + {% include-markdown "./reduce_reporting_friction.md" start="" end="" %} + +
diff --git a/docs/howto/initiation/reduce_reporting_friction.md b/docs/howto/initiation/reduce_reporting_friction.md new file mode 100644 index 0000000..f2ccc69 --- /dev/null +++ b/docs/howto/initiation/reduce_reporting_friction.md @@ -0,0 +1,93 @@ +# Reduce Friction in the Reporting Process + +As a vendor, it is important to not treat reporters with suspicion or +hostility. It's likely they have important information about your +product, and they want to share it with you. +Furthermore, vendors should take care not to frustrate reporters' +attempts to make contact by building too many assumptions into their CVD +process. + +In the course of our own vulnerability coordination efforts, we have +observed all of the following erroneous assumptions built into vendor's +CVD process: + +
+!!! failure "The vendor and the reporter are engaged in a binding two-way negotiation." + + This is false for at least two reasons: First, the + reporter noticed an observable fact about a product flaw, and + they're free to tell whomever they please. Similarly, the vendor is + not obliged to keep the reporter in the loop once the report is + received. And while it might be possible to eventually constrain the + reporter or vendor contractually, that's not a foregone conclusion + at the outset. Secondly, there exist adversaries who are entirely + indifferent to whatever reporter-vendor agreements about disclosure + might be reached, so even the most strictly binding agreement + between vendor and reporter can be rendered irrelevant by events + beyond either party's control. + +!!! failure "The reporter will wait indefinitely for your reply before communicating with others about what they know." + + Technology + sometimes fails, and we wonder if a message was received. It is + helpful to let the reporter know as soon as possible that the report + was received. Give regular updates on the process so that the + reporter is involved and there is mutual understanding. If reporters + are kept out of the loop, they may seek out a third-party + coordinator or even publish their report without notice. + +!!! failure "The reporter is always a customer or has a customer ID." + + At the + CERT/CC, we have hit walls in our communication attempts when a + vendor's technical support function refuses to help us without a + customer ID number. Be sure your tech support staff understand how + to forward vulnerability reports to the appropriate individuals or + groups within the organization. Vulnerability reports can arrive + from anyone. + +!!! failure "The reporter has an account on your private portal." + + The + reporter may not be a customer with a portal account; furthermore, + the reporter may wish to remain anonymous and will be unwilling to + register for a portal account. Again, be sure it is easy for + reporters to find more than one communication channel. + +!!! failure "The reporter is willing to sign an NDA." + + Some reporters will not sign an NDA. + And they shouldn't have to. + Remember that the reporter's participation in CVD is voluntary. + Be sure your process can accommodate reporters who are unwilling to sign an NDA. + Better yet, avoid NDAs altogether for vulnerability reports. + +!!! failure "The reporter can send or receive encrypted mail." + + The CERT/CC encourages encrypted mail when possible, but it is not appropriate + to presume all reporters can or must use encrypted mail. If the + reporter declines to use encrypted mail, offer other options. These + may include encrypted zip files or a company upload service such as + FTP. + +!!! failure "The reporter is willing and/or able to fill out a web form." + + Some reporters prefer to use anonymous email; be sure you have more + communication lines open than just a web form. + +!!! failure "The reporter is a human." + + Sometimes reports can be auto-generated by tools. Include a clearly defined reporting format + for tools if at all possible. + +
+ +!!! failure "The reporter will keep your correspondence private." + + Lack of + response or rudeness on the part of a vendor may result in the + reporter choosing to post the correspondence publicly. In addition + to the negative attention this draws to the vendor and reporter + alike, such negative experiences may discourage finders and + reporters from reporting vulnerabilities to the vendor in the + future. diff --git a/docs/howto/initiation/unresponsive_vendor.md b/docs/howto/initiation/unresponsive_vendor.md new file mode 100644 index 0000000..5ae260e --- /dev/null +++ b/docs/howto/initiation/unresponsive_vendor.md @@ -0,0 +1,35 @@ +# Unresponsive Vendor + +Sometimes, even when you can [find contact informaiont for the vendor](find_vendor_contact.md), +not all vendors have established processes for receiving vulnerability reports. +Potential reasons abound: + +- They haven't thought about it, even though they should have. +- They don't realize they need it, even though they do. +- They think their software process is already good enough, even if + it's not. +- They assume anyone reporting a problem is an evil hacker, even + though they're wrong. + +!!! example "FTC Actions Against Vendors" + + The U.S. Federal Trade Commission has brought legal action against + vendors for not having sufficient vulnerability response capabilities. + In their complaint against [ASUS](https://www.ftc.gov/enforcement/cases-proceedings/142-3156/asustek-computer-inc-matter), they cite the company's failure + to + + > maintain an adequate process for receiving and addressing security + > vulnerability reports from third parties such as security researchers + > and academics;...perform sufficient analysis of reported + > vulnerabilities in order to correct or mitigate all reasonably + > detectable instances of a reported vulnerability, such as those + > elsewhere in the software or in future releases; and\...provide + > adequate notice to consumers regarding (i) known vulnerabilities or + > security risks, (ii) steps that consumers could take to mitigate such + > vulnerabilities or risks, and (iii) the availability of software + > updates that would correct or mitigate the vulnerabilities or risks. + + Similar complaints have been included in FTC filings against [HTC America](https://www.federalregister.gov/documents/2013/02/28/2013-04606/htc-america-inc-analysis-of-proposed-consent-order-to-aid-public-comment) + and [Fandango](https://threatpost.com/ftc-settles-with-fandango-credit-karma-over-ssl-issues-in-mobile-apps/105128/). + +{% include-markdown "../recipes/_x06.md" heading-offset=1 %} diff --git a/docs/howto/initiation/useful_reports.md b/docs/howto/initiation/useful_reports.md new file mode 100644 index 0000000..09f1ec6 --- /dev/null +++ b/docs/howto/initiation/useful_reports.md @@ -0,0 +1,37 @@ +# Providing Useful Information in a Vulnerability Report + +Reporting a vulnerability requires that the vulnerability is +well-documented. This typically means providing high-quality and actionable +information to the vendor or coordinator. + +This information should be detailed enough to allow the vendor to understand +the vulnerability and take appropriate action to fix it. + +!!! example "What to Include in a Vulnerability Report" + + When reporting a vulnerability, it is important to include the following + information: + + - The exact product version(s) affected + - A description of how the vulnerability was discovered (including + what tools were used) or what you were doing when you encountered + the vulnerability + - Proof of concept (PoC) code or reproduction instructions + demonstrating how the vulnerability might be exploited + - Ideally, a suggested patch, remediation, or mitigation action(s) if the reporter is + aware of how to fix the vulnerability + - Description of the impact of the vulnerability and attack scenario + - Any time constraints (for example, give a date of publication or + presentation at a conference if you know) + + + +!!! tip "Use the Common Weakness Enumeration (CWE) or Common Attack Pattern Enumeration and Classification (CAPEC)" + + Reporters that do not provide enough information to a vendor or + coordinator may find their reports delayed or even rejected. Using the + [Common Weakness Enumeration](https://cwe.mitre.org) or + the [Common Attack Pattern Enumeration and Classification](https://capec.mitre.org) + as a reference might be helpful to describe the + type of vulnerability you have found and common ways to fix it the + problem. diff --git a/docs/howto/operation/_cvd_platform.md b/docs/howto/operation/_cvd_platform.md new file mode 100644 index 0000000..bac2d92 --- /dev/null +++ b/docs/howto/operation/_cvd_platform.md @@ -0,0 +1,54 @@ +!!! tip "CVD Platforms and Turnkey Services" + + !!! example inline end "CVD Platform Providers" + + Some popular CVD platform providers include: + + - [BugCrowd](https://bugcrowd.com/) + - [HackerOne](https://www.hackerone.com) + - [SynAck](https://www.synack.com) + - [Cobalt](https://cobalt.io/) + + A number of third-party CVD platforms now exist to facilitate + communication between vendors and reporters. Although + they are often referred to as bug bounty platforms, the _bounty_ + aspect is in fact optional—vendors can use CVD platforms to + receive reports without needing to compensate reporters unless they + choose to do so. + + + CVD platforms provide a secure communications channel (HTTPS) for + reporters to communicate with vendors. These platforms generally allow + two-way communications, making it easy for ongoing discussion between + vendor and reporter. This channel is usually hosted by a third party in + a software-as-a-service model, which may be important to some + organizations that are not able to maintain their own infrastructure due + to resource constraints. Of course, having vulnerability information + hosted on third-party infrastructure may also present a data privacy + risk to some organizations, so it is important to consult internal + policies before determining if a CVD platform fits your organization's + needs and requirements. + + !!! example "DoD's Vulnerability Disclosure Program" + + The U.S. Department of Defense (DoD) has a [Vulnerability Disclosure + Program](https://www.dc3.mil/Missions/Vulnerability-Disclosure/Vulnerability-Disclosure-Program-VDP/) + (VDP) that uses a [CVD platform](https://hackerone.com/deptofdefense) + to receive reports from + security researchers. The DoD VDP is a public program that allows + security researchers to report vulnerabilities in DoD websites and + systems. The DoD VDP is a good example of a CVD platform that + is used to facilitate communication between reporters and vendors, + even without an explicit bug bounty program. Reporters to the DoD VDP + are not compensated monetarily for their reports, but they are able to + gain recognition and reputation points within the CVD platform that can + lead to future opportunities for paid work. + + !!! note "CVD Platforms and Account Creation" + + An important note regarding these platforms is that the CVD platform by + its nature requires a login. As explained [previoiusly](./secure_comms.md), + requiring an account may discourage some reporters or other + organizations from joining the platform, locking them out of discussion. + Organizations should consider whether the benefits of using a CVD + service outweigh this concern. diff --git a/docs/howto/operation/case_tracking.md b/docs/howto/operation/case_tracking.md new file mode 100644 index 0000000..80f2ffe --- /dev/null +++ b/docs/howto/operation/case_tracking.md @@ -0,0 +1,39 @@ +# Case and Bug Tracking + +Case tracking systems such as bug trackers or trouble ticket systems are +often used by +[vendors](../../topics/roles/vendor.md), +[coordinators](../../topics/roles/coordinator.md), and +[reporters](../../topics/roles/finder.md) for tracking vulnerability +reports. Such systems can centralize the vulnerability +response process and provide the ability to track individual cases. Case +tracking systems also provide a means of collecting data about recurring +security issues and the performance of the response process itself. + +!!! tip "Vulnerability Reports vs. Bug Reports" + + We have found it important to distinguish that vulnerability reports are + not always bug reports. A single vulnerability report might contain + information on more than one bug; alternately, it may describe a + configuration issue that would not typically be considered a bug in the + first place. In general, vulnerability reports and bug reports should be + thought of as having a many-to-many relationship, allowing one or more + vulnerability reports to be linked to one or more bug reports. + + That said, bug tracking systems can still be useful for vulnerability + report tracking if this distinction is kept in mind, and the bug + tracking system has the appropriate capabilities. + +!!! tip "MPCVD and Case Tracking" + + At the CERT/CC, we've found that more complicated CVD cases—for example the multiparty cases + described in [MPCVD](../coordination/mpcvd.md)—become more like projects than tickets. + In the context of MPCVD, multiple organizations may be involved in the response + process, and each organization may have its own case tracking system. + + We have been working on the development of a protocol for sharing case + information across organizations, which we hope will help to address some of these + challenges. The [Vultron Protocol](https://certcc.github.io/Vultron) is a work in progress + that aims to provide interoperability across organizations' CVD processes. + +{% include-markdown "./_cvd_platform.md" heading-offset=1 %} diff --git a/docs/howto/operation/contact_management.md b/docs/howto/operation/contact_management.md new file mode 100644 index 0000000..79f54a9 --- /dev/null +++ b/docs/howto/operation/contact_management.md @@ -0,0 +1,48 @@ +# Contact Management + +From a reporter's perspective, the contact management process can be +relatively simple. For most reporters, the contact management process simply consists of +finding and bookmarking a vendor's security contact page, or +maintaining a vendor's email address and PGP/GPG key in compatible mail +client software. + +Contact management becomes vitally important to +multiparty CVD, and is a particular concern for third-party +coordinators. + +!!! tip "Finding Vendor Contacts" + + Finding vendor contacts can be difficult. Not all vendors include + contact information in an easily searchable page, such as a Contact Us + page linked from the vendor's homepage. + See [Finding Vendor Contacts](../initiation/find_vendor_contact.md) for more information. + +!!! warning "Avoid Posting Vulnerability Details in Public" + + In order to protect privacy during the disclosure process, mailing lists + or simply carbon-copying all recipients to a single message is likely + not an acceptable action in most scenarios. Vendors in many cases would + like to keep their vulnerability information private except for what is + specifically intended to be shared. + +!!! example "CERT/CC's Approach to Contact Management" + + For the first few decades of the CERT/CC's existence, we developed and maintained a collection of + in-house tools and scripts to perform contact and key management. + These tools auto-generated individual encrypted emails, one for each vendor we attempted to reach. + In this way, we could maintain privacy up front, with the option to introduce two vendors should there be + mutual interest in collaboration. This approach was particularly useful for smaller cases. It serves as an example of a + _hub and spoke_ topology for each case. + + However, we eventually realized that this approach was not scalable to larger cases involving multiple vendors, + and much of our coordination work was shifting toward multiparty cases. + With the rollout of the [VINCE platform](https://github.com/CERTCC/VINCE), we have shifted to a _shared bus_ topology + for our cases, in which the reporter, vendors, and coordinators all have access to the same case information and + can communicate with each other in a shared space. + While we still have some manual processes for making the initial contact with vendors, the VINCE platform + allows vendors to manage their own contact information and PGP keys within the system. + This has enabled us to scale our operations to handle more cases involving many more vendors, + and has made it easier for us to bring in third-party coordinators to assist with + cases when necessary. + + We cover communication topologies for CVD in [Response Pacing and Synchronization](../coordination/response_pacing.md). diff --git a/docs/howto/operation/index.md b/docs/howto/operation/index.md new file mode 100644 index 0000000..5d09495 --- /dev/null +++ b/docs/howto/operation/index.md @@ -0,0 +1,30 @@ +# Ongoing Coordination Operations + +Participating in a CVD process over time requires a set of tools and +practices in order to be successful. In this section, we outline a few +tools of the trade, and consider common operational security and +personnel management issues. + +
+ +- :material-tools: **Tooling** + + --- + - [Secure Communications](secure_comms.md) + - [Contact Management](contact_management.md) + - [Case Tracking](case_tracking.md) + +- :fontawesome-solid-person-digging: **Practices** + + --- + - [Technical Analysis](technical_analysis.md) + - [Monitoring](monitoring.md) + - [Operational Security](opsec.md) + - [Staffing Considerations](staffing.md) + +
+ +!!! tip "Process Improvement is Key Principle of CVD" + + See also [Process Improvement](../../topics/principles/process_improvement.md) for more + about how to improve your CVD process over time. diff --git a/docs/howto/operation/inventory.md b/docs/howto/operation/inventory.md new file mode 100644 index 0000000..c40c618 --- /dev/null +++ b/docs/howto/operation/inventory.md @@ -0,0 +1,103 @@ +# Code and System Inventories + +For both vendors and deployers, maintaining an inventory of dependencies +is a critical part of the vulnerability management process. Knowing what +you have deployed is the first step in being able to protect it. + +## Deployer Perspective: What's in Your Network? + +For deployers, maintaining an inventory of the software and hardware in +your network is a critical part of your vulnerability management +process. Knowing what you have deployed is the first step in being able +to protect it. This is especially important for software that is exposed +to the internet, but it is also important for software that is only used +internally. + +Even better than just knowing what you have deployed is being able to map +those deployed components to the important services they provide and the +missions they support. This can help you prioritize your response to +vulnerabilities based on the importance of the affected systems. + +!!! ssvc "SSVC and risk-based prioritization" + + We developed the [Stakeholder-Specific Vulnerability Categorization](https://certcc.github.io/SSVC) + (SSVC) framework to help organizations prioritize their vulnerability + response efforts based on the importance of the affected systems to + the organization's mission, along with exposure to adversaries. + SSVC is a risk-based approach to vulnerability prioritization that + can help organizations to focus their efforts on the most risk-relevant + vulnerabilities first. + +## Vendor Perspective: Dependencies and Supply Chain + +As we discuss in [Multiparty CVD](../coordination/mpcvd.md), +software-based products are typically assembled from components rather +than written from scratch. Economies of scale apply to code, and most +organizations would consider it wasteful to write a feature from scratch +when that feature is available at a reasonable licensing cost for +inclusion into their own products. As a result, each product is not +merely the result of a single vendor's development process, but of an +entire supply chain. Libraries get included in other libraries, which +form subcomponents in the composition of larger and more complex +products. + +!!! tip "Know Your Dependencies" + + For product vendors, an important part of the vulnerability response + process is knowing what weaknesses your products might have. You can + address this by clearly identifying any third-party libraries or + utilities that are included with your products, and being alert and + responsive to vulnerability disclosures in any third-party products that + may affect your own products. + +!!! tip "Software Bill of Materials (SBOM)" + + Because it is likely that your products will in turn be used + as components in some other vendor's solution, it is increasingly a good + practice to provide an inventory of components along with your product. + Under the broad category of [Software Bill of Materials](https://www.cisa.gov/sbom) + (SBOM), this practice is becoming more common in the software industry. + A number of data formats and specifications have emerged in the software + supply chain management space and are in use by product vendors already. + + These include the following + + - [Software Identification (SWID) Tags](http://tagvault.org/swid-tags/) + - [Common Platform Enumeration (CPE)](https://nvd.nist.gov/products/cpe) + - [The Software Package Data Exchange (SPDX)](https://spdx.org/) + + More than just a good practice, providing an SBOM can be a requirement + in some industries. For example, the U.S. government has issued an + [Executive Order](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) + that mandates the use of SBOMs in software procurement. + The National Telecommunications and Information Administration (NTIA) + has also issued a report describing + [_The Minimum Elements For a Software Bill of Materials_](https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom) + +!!! example "Software Composition Analysis Tools" + + In recent years, a class of Software Composition Analysis tools (such + as those offered by + [Mend.io](https://www.mend.io/), + [Synopsys](https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html), + [Sonatype](https://www.sonatype.com/), + and + [Revenera](https://www.revenera.com/software-composition-analysis)) + have come into use to identify potential licensing conflicts in + commercial and open source products. Many of these tools are + potentially useful to vendors looking to create an inventory of + libraries and third-party components used in their products for + security analysis purposes as well. + +!!! tip "Monitoring For Vulnerabilities in Third-Party Components" + + As a vendor, identifying your products' third-party dependencies is + only the first step. After that, you should take steps to ensure that + your vulnerability response capability maintains awareness of any + security-related announcements about those upstream products on which + your product depends. Some component vendors offer special communication + channels (e.g., a mailing list) for their licensees. If you've worked + with a coordinator like the CERT/CC in the past, ask if you can be + placed in a special notification list for a particular library or + product. + See more in [Monitoring](./monitoring.md). diff --git a/docs/howto/operation/monitoring.md b/docs/howto/operation/monitoring.md new file mode 100644 index 0000000..588a529 --- /dev/null +++ b/docs/howto/operation/monitoring.md @@ -0,0 +1,60 @@ +# Monitoring + +CVD participants should maintain some level of monitoring for external activity that may materially affect their +prioritization or decision-making while handling a case. + +## What to Monitor For + +While cybersecurity monitoring is a practice unto itself, there are some specific things that CVD participants should be on the lookout for +because they can affect the handling of a case. Items most directly relevant include: + +| Type of Activity | Description | +|-----------------------------------------|-------------------------------------------------------------------------------------------| +| Early publication outside of an embargo | Information about a vulnerability or exploit is made public before the embargo is lifted. | +| Exploit made public | An exploit for a vulnerability is made public. | +| Attacks observed | Attacks are observed in the wild. | +| Parallel discovery | Someone else finds the same vulnerability. | +| Vulnerabilities in upstream components | Vulnerabilities are discovered in components that your product depends on. | + +
+ +!!! tip "Advice for Vendors" + + Vendors need to monitor for public information about security vulnerabilities in their products. Knowing about attacks and published exploits is key. + Furthermore, for vendors that use third-party components, monitoring for vulnerabilities in those components is also important. + +!!! tip "Advice for Deployers" + + Deployers need to monitor for public information about security vulnerabilities in the systems they have deployed (including reports coming as a result of the vendor's CVD process). + They need to be on the lookout for fix announcements, mitigation advice, exploits, and attacks. + +
+ +Although usually less-specific to individual cases, the following are also important to monitor for anyone involved +in vulnerability management: + +| Type of Information | Description | +|-----------------------|---------------------------------------------------------------------------| +| Other vulnerabilities | Other vulnerabilities are discovered that may affect your infrastructure. | +| Adversary "chatter" | Adversaries discussing a vulnerability or exploit. | +| New TTPs | New adversary tactics, techniques, or procedures are observed. | + +## Information Sources + +The following are some of the sources that CVD participants might choose to monitor: + +| Monitoring Source | Description | +|--------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Inventory | Paying attention to your infrastructure so you know what you have at risk. | +| Threat Feeds | Paying attention to the world so that you have some sense of what adversary capabilities are. You want to know when adversaries gain new capabilities, like new TTPs. | +| Threat Hunting | Paying attention to what adversaries are potentially doing on your infrastructure. | +| DFIR & Malware analysis | Paying attention to what has already happened and the artifacts left behind by adversaries to notice when they gain new capabilities. | +| Media reports | Paying attention to what the world knows about vulnerabilities and exploits. | +| Conference presentations | Paying attention to what the technical and research community knows about vulnerabilities and exploits. | + +!!! info "CERT RMM Monitoring Process Area" + + The [Monitoring Process Area](https://insights.sei.cmu.edu/library/monitoring-mon-cert-rmm-process-area/) (MON) + of the [CERT Resilience Management Model](https://insights.sei.cmu.edu/library/cert-resilience-management-model-cert-rmm-collection/) (CERT-RMM) + includes practices surrounding monitoring for security events, incidents, and other operationally relevant information. + The CERT-RMM is a process improvement model designed to help organizations to improve their operational resilience. diff --git a/docs/howto/operation/opsec.md b/docs/howto/operation/opsec.md new file mode 100644 index 0000000..2a5e718 --- /dev/null +++ b/docs/howto/operation/opsec.md @@ -0,0 +1,111 @@ +# Operational Security + +Operational security, often shortened to "opsec," is an important part +of CVD operations. Opsec includes your ability to maintain security and +confidentiality for information associated with vulnerability reports +prior to disclosure. + +## Handling Sensitive Data + +Some of the information that passes through a CVD process may include information on an +organization's internal processes, trade secrets, or even national +security interests in some scenarios. Proper precautions need to be +established. It is recommended that recipients treat all received data +as private unless explicitly given permission to share. + +Of course, there is some ambiguity when you say private: does that mean +the information is for the whole organization? Just the +CVD team? Possibly even a single analyst? + +!!! tip "Need-to-Know Principle" + + The "need-to-know" principle is a good starting point for determining + who should have access to sensitive information. This principle + states that only those who need to know the information to perform + their job should have access to it. + In general, vulnerability information should be + shared with the fewest number of people possible to effectively + coordinate and remediate or mitigate a vulnerability prior to disclosure. Clearly + declaring the data's sensitivity can help to make that determination. + +### Traffic light Protocol + +The [Traffic Light Protocol](https://www.first.org/tlp) is managed by the Forum of Incident Response and Security Teams (FIRST). +It is a set of designations used to ensure that sensitive information is shared with the appropriate audience. +By marking a document with a TLP level, a sender can easily communicate the sensitivity of +information and expectations about sharing it further. + +TLP 2.0 has five levels, each with a different meaning: + +| Label | Description | +|-------|-------------| +| **TLP:RED** | For the eyes and ears of individual recipients only, no further disclosure. | +| **TLP:AMBER+STRICT** | Limited disclosure, recipients can only spread this on a need-to-know basis within their organization only. | +| **TLP:AMBER** | Limited disclosure, recipients can only spread this on a need-to-know basis within their organization and its clients.| +| **TLP:GREEN** | Limited disclosure, recipients can spread this within their community. | +| **TLP:CLEAR** | Recipients can spread this to the world, there is no limit on disclosure. | + +!!! tip "TLP Levels and CVD" + + We recommend using **TLP:AMBER** for most cases prior to public disclosure. + + In the context of CVD, the following applies: + + - **TLP:GREEN** and **TLP:AMBER** are best suited for information shared between reporters, vendors, and coordinators during phases prior to + public announcement of a vulnerability. + + - If pre-publication announcements are made to deployers or other stakeholders, + **TLP:AMBER+STRICT** could be a good fit. + + - **TLP:RED** would usually be reserved for very sensitive information. + + - **TLP:CLEAR** is most useful for public disclosures. + +{% include-markdown "../../_includes/tlp_red_amber_strict_warning.md" heading-offset=1 %} + +## Don't Automatically Trust Reports + +There are two reasons that organizations receiving vulnerability reports +should maintain a degree of wariness regarding the reports they receive. +The first is intentional misdirection of your CVD capability, which we +already discussed in [Validation](../../topics/phases/validation.md) and +[Prioritization](../../topics/phases/prioritization.md). +The second is subtler, in +that the technical infrastructure you deploy to manage CVD cases can +potentially be affected by the vulnerabilities you are coordinating. + +Vulnerability reports may contain hostile attachments—not necessarily +as an attack, but simply a reporter sending a proof-of-concept for your +review—so vendors and coordinators should design their report tracking +systems and process accordingly. + +!!! tip "Isolate Attachments" + + Be sure attachments to vulnerability + reports are not opened automatically anywhere along the process. You + might also institute a policy that such attachments are only to be + opened within an isolated testing environment, not on production + systems. + +CVD participants should keep in mind that their [case tracking](case_tracking.md) and [email +systems](secure_comms.md) themselves present attack surface and may be affected by the +very vulnerabilities they are designed to coordinate. We have witnessed +reports containing examples of image parsing vulnerabilities causing +problems for both webmail and ticketing systems that automatically +generate thumbnail previews of image attachments. + +!!! tip "Consider Separate Infrastructure" + + Vendors and + coordinators concerned about such risks should consider the degree to + which their CVD support infrastructure is integrated with normal + business operations systems. In some scenarios, maintaining parallel + infrastructure may be preferable. + +### Complex Communications Reduce Trust + +It's also important to be aware that not all participants along the +chain of disclosure will be equally trustworthy. That's not to say they +are actively malicious, just that they may have incompatible values or +priorities that lead them to disclose the existence of the vulnerability +to others earlier than you'd prefer. diff --git a/docs/howto/operation/pgp.md b/docs/howto/operation/pgp.md new file mode 100644 index 0000000..384fb7b --- /dev/null +++ b/docs/howto/operation/pgp.md @@ -0,0 +1,96 @@ +# PGP/GPG Key Management + +Separate from the issue of maintaining encryption keys for your +contacts, you must also maintain your own individual or organizational +encryption key. + +PGP/GPG is a form of asymmetric encryption that makes use of two +different encryption keys called your *public key* and your *private +key*. The public key is intended to be shared; you advertise your public +key, and individuals or organizations wishing to contact you use your +public key to encrypt a message. Messages encrypted to your public key +can only be decrypted by the private key; therefore, it is important +that your private key stays private, and that no one outside of your +team or organization has access to this key. + +A general discussion on encryption algorithms is beyond the scope of +this documentation, but at the time of this writing, it is recommended to +generate RSA keys with a length of at least 4096 bits to ensure security +into the near-to-moderate-term future. + +## Use a Passphrase and Control Access + +We recommend setting a strong passphrase on any key. Without a +passphrase, anyone who obtains the key file can immediately use the key +to sign messages or decrypt messages; if the private key is leaked to +unauthorized users but a passphrase was applied, then the user would +need to also know the passphrase before any damage could be done. + +Of course, a persistent attacker could attempt to brute force the +phrase, so ideally the private key should be kept somewhere safe, out of +the hands of any unauthorized users. In other words, only members of the +CVD team should know the passphrase or even have access to the key file. +Ideally, if your CVD capability includes a dedicated communications +team, restrict knowledge of the passphrase and access to the key +material only to those members directly involved with communications. At +the CERT/CC, we have implemented this by having dedicated systems for +CVD communications work; private keys are only accessible from these +systems. In this setup, users must specifically request access and can +be allowed or denied based on need. + +### Use Revocation Certificates and Key Rotation + +A concern is that the private key may land into unauthorized hands. This +might occur in the event of a network breach, but another possibility is +a disgruntled former employee retaining a copy of the key. Because of +these possibilities, organizations using shared key material should +generate a revocation certificate for their PGP/GPG key and store it +somewhere safe. Obviously, it is important to restrict access to the +passphrase and revocation certificate; typically, it should only be +accessible by management. Should any emergency or security event occur, +you can publish the revocation certificate to notify the public to not +trust this key anymore. When a user imports your revocation certificate, +it marks the associated PGP/GPG key as unusable and untrustworthy. + +To further mitigate these concerns, we recommended that you rotate +encryption keys (i.e., generate a new one) regularly. Some teams choose +to use the same key for two, three, or more years without change. This +recommendation arises to address concerns regarding the threat of +network breaches and the potential impact of losing control of the +private key. At the CERT/CC, we generate a new PGP/GPG key yearly. + +Another reason to rotate keys is to revoke access to future encrypted +email when analysts leave the CVD team. The best way to do this is to +generate a new key whenever there are personnel changes; in this way, +future messages will be encrypted to the new key with a new passphrase, +and any former team members will be unable to access these messages even +if they still have access to the old key. + +Regardless of how often you generate a new PGP key, your latest PGP +public key needs to be available to individuals and organizations so +that they may contact you. Be sure your key generation process includes +necessary steps to put your PGP public key in the public's hands. This +can consist of posting your PGP public key directly to your organization +website, or pushing your key to one of many PGP public key servers. You +can use these same mechanisms to distribute your revocation certificate +should the need arise. + +## Practical Tips for Key Management + +We wrap up this discussion with a review of recommended practices for +PGP/GPG key management: + +- Generate an RSA key of at least 4096 bits. +- Restrict access to the private key material. +- Use a strong passphrase on the key. +- Restrict knowledge of the key passphrase to only those members of + the CVD team involved in communications. +- Generate a revocation certificate for each key. +- Store the key passphrase and a revocation certificate in a safe + location, such as a locked cabinet or safe in a secured area of the + organization. +- Generate a new key whenever a member leaves the CVD team, and revoke + the old key. +- Generate a new key periodically, regardless of other factors. +- Make your latest public key available in a known location to ensure + recipients always have access to the latest key. diff --git a/docs/howto/operation/secure_comms.md b/docs/howto/operation/secure_comms.md new file mode 100644 index 0000000..5a8c0be --- /dev/null +++ b/docs/howto/operation/secure_comms.md @@ -0,0 +1,219 @@ +# Create Secure Channels for Reporting + +Whether you are a vendor or a coordinator, you need to have open +channels for communication with vulnerability finders and reporters. +Secure communications can be nuanced to maintain in operation, so we have compiled +some advice about establishing and maintaining this capability. + +## Web Forms and Portals + +Most vulnerability reports have a similar structure, making a web form a +preferable method for receiving vulnerability reports for many +organizations. + +!!! tip "Focus on Encrypted Transport and Strong Authentication" + + If you're starting a new CVD program, we recommend focusing on encrypted transport and strong authentication. + Don't build a new process around PGP / GnuPG and email. + Some vendors choose to offer a web form specifically for receiving reports of security-related issues. + Such forms can then deliver the report directly to your security or engineering team. + +!!! tip "Have a Dedicated Form for Security Reports" + + The CERT/CC discourages reliance on general "Contact Us" web forms that + pass through an organization's communications or customer support + teams. Many finders will balk at having to get past these nontechnical + interfaces into the vendor. In addition, security messages often must be + triaged and processed differently than other incoming contacts. + + To secure your web form, you will need to enable HTTPS + and TLS, and obtain a TLS certificate from a Certificate Authority (CA). + A free option is [Let's Encrypt](https://letsencrypt.org/), maintained by the [Internet Security + Research Group](https://www.abetterinternet.org/about/) (ISRG). + + Coordination tools like VINCE or coordination platforms can be a good choice, or + you can make use of a third-party bug bounty or coordination platform. + +!!! tip "Do you need a login to report?" + + TLS ensures that the transmission is secure, but does not authenticate + who sent the report. If this is a requirement, you may also need to + implement login accounts on your web form with adequate authentication + mechanisms such as two-factor or X.509 certificates. However, this setup + increases the complexity for reporters to provide information to you, + and as a result is rare in practice and likely unnecessary. Once set up, + an HTTPS web form provides an easy-to-use way for reporters to contact + you with vulnerability reports and other information. + + However, a problem does come up: how do you acknowledge receipt of the report + and continue the conversation? + + Possibilities include the following: + + - *Echoing back the message in a confirmation email.* The reporter + knows you received the text, but now the text was sent in plain text + email for everyone to read. It is unlikely you want to do this. + + - *Send a brief thank you message, but without details.* The reporter + can now be assured that the report was received. But what if you + have a follow up question for the reporter? It's likely you will + need to send an email, which will require encryption to keep the + details of the question and answer secure. + + - *Send a brief thank you message, and ask the reporter to log in to a + portal to view the message conversation.* This resolves the issue of + two-way secure communications, but now you need to establish a + public-facing portal and manage portal credentials. This raises + additional operational considerations, for example those below: + + - user account management and password changes + + - two-factor authentication or X.509 as possible requirement to ensure + user identity + + Portal credential maintenance introduces more complications, and for + many vendors may not be worth the effort. Another disadvantage of + using a portal is that vendors and organizations may be unwilling to + create accounts on another vendor's portal. This may discourage + multi-party communication and coordination, effectively preventing a + vendor or reporter from participating in multi-party CVD. + +{% include-markdown "./_cvd_platform.md" heading-offset=1 %} + +## Email + +Email is a simple, tried-and-true method of communication over the +Internet. Simply because everyone has access to it, email is likely to +remain a common way of receiving vulnerability reports and +communications. + +
+ +!!! tip "Email is the Universal CVD API" + + In our experience, email is still a very common way to receive + vulnerability reports. It serves as a sort of universal API for CVD, + regardless of what other tools might be in use. + For this reason, the CERT/CC recommends that vendors establish a specific + and well-publicized email alias such as `security@example.com` solely + for receipt of vulnerability reports, even if they have other + communication channels available. + +!!! warning "Email is Insecure by Default" + + Email by itself is not a secure medium. We recommend that emails + containing sensitive information be encrypted \[2\]. This includes + emails containing information about unpatched or otherwise sensitive + vulnerabilities. + +
+ +!!! tip "Avoid Using Personal Email Addresses for Security Contact" + + Because of the potential for organizational changes like + employee promotions and turnover, having an individual's email address + as a security point of contact is generally discouraged. A better + solution is to establish an email account specifically for vulnerability + reports and CVD activity. Many vendors choose to reserve an email + address like `security@example.com` or `psirt@example.com` for + this purpose. + +!!! tip "Make Your Security Contact Information Easy to Find" + + The CERT/CC recommends that vendors make their security contact + information easy to find, for example on the Contact Us page of their + website. + + Ideally, an Internet search for ` report vulnerability` + should lead to that contact information. The security email account + should be an alias that is forwarded to or shared by one or more people. + This way, multiple team members can check the incoming mail and cover + for each other when team members are out of the office. Even if the + security team is only one person, having an alias makes it easier to + adapt should that person leave the organization; to the outside world, + no contact information needs to change. + + The IETF's [RFC 2350](https://datatracker.ietf.org/doc/html/rfc2350) + _Expectations for Computer Security Incident Response_ (aka BCP-21) + suggests you include contact information as + part of your overall CSIRT disclosure policy and process publication. + [RFC 9116](https://datatracker.ietf.org/doc/html/rfc9116) + _A File Format to Aid in Security Vulnerability Disclosure_ + See the [security.txt](https://securitytxt.org/) site for more. + +!!! warning "Email is No Substitute for a Case Tracking System" + + Although receiving information via email is convenient, it is not a very + good mechanism for tracking multiple cases at once. Rather than sending + security emails to individual mailboxes, vendors, coordinators, and even + large-scale reporters should consider setting up a web-based case + tracking system instead. That way, received emails can automatically + generate new cases or augment existing ones, which can then be assigned + to team members and tracked as necessary. More on this topic can be + found in [Case Tracking](case_tracking.md). + +!!! tip "Managing Email Encryption" + + Although we primarily recommend web-based case tracking systems for + managing communications in CVD, email encryption can still be useful + for securing sensitive information in transit. + + Since email is an insecure communications channel by default, + many vendors, reporters, and coordinators prefer to use encrypted mail + instead. Although x.509 encrypted mail exists, we have found + PGP-compatible tools such as GnuPG to be more widely used by CVD + participants. Vendors are encouraged to create and publish a PGP key + affiliated with the security email alias to allow the confidentiality of + sensitive reports to be maintained in transit. + + A common choice used to be Thunderbird with [Enigmail](https://enigmail.net/index.php/en/), but + Thunderbird is no longer supported by the Enigmail project. + Alternative mail clients for Enigmail include + [SeaMonkey](https://seamonkey-project.org/), + [Epyrus](http://www.epyrus.org/) and [Postbox](https://postbox-inc.com/). + + Other open source solutions such as Outlook with [gpg4win](https://www.gpg4win.org/), or [KMail](https://apps.kde.org/kmail2/) + with [KGpg](https://apps.kde.org/kgpg/) and/or [Kleopatra](https://www.openpgp.org/software/kleopatra/) + and proprietary solutions such as + [PGP Encryption Desktop](https://techdocs.broadcom.com/us/en/symantec-security-software/information-security/symantec-encryption-desktop/11-0-0.html) also exist. + A collection of email encryption tools can be found on + [OpenPGP](https://www.openpgp.org/software/)'s website. + +!!! info "How Our Approach has Changed" + + The CERT/CC has used email as the primary means of communication for + many years. However, as our operations have scaled up, we have found + that email is not always the best way to manage multiple cases + simultaneously. We have since developed a web-based case tracking + system called [VINCE](https://www.kb.cert.org/vince/) to help us manage + our cases more effectively. + + While email still has its place in our CVD operations, we have found that + PGP / GnuPG is overly complicated for many of the folks we need to coordinate with, + reporters and vendors alike. + +!!! question "What happened to PGP/GnuPG?" + + PGP / GnuPG, never popular outside of the infosec community, has been falling out of + favor in the past decade. + Some notable commentary includes: + [What's the Matter with PGP?](https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/), + [GnuPG and Me](https://moxie.org/2015/02/24/gpg-and-me.html), and + [I’m throwing in the towel on PGP, and I work in security](https://arstechnica.com/information-technology/2016/12/op-ed-im-giving-up-on-pgp/). + + PGP and GnuPG are highly prone to user error, and the consequences of those errors can be severe + (e.g., sending a private key to the wrong person). The tools are also difficult to manage at scale. + + Encrypted email was intended for one-to-one communication, but in CVD, we often have teams of people + from different organizations working together. In this scenario, the team often has a single key. + Everyone outside the team encrypts to that one key, but on the receiving side, + the email is often decrypted and forwarded as plain text within the team (e.g., posted to a case tracking system). + For all practical purposes, the email encryption is just serving as transport encryption rather than end-to-end + from sender mail client to receiver mail client. But other technology like StartTLS already enables transport encryption, + and that is usually configured by mail server administrators who are more likely to get it right than individual users. + It's not clear that the additional complexity adds much value. + + Finally, there is the question of what the threat model is. In other words, who are you trying to protect against? + A highly skilled adversary can likely get access to the key material itself, or to the contents of the email in + plain text before encryption or after decryption. A less skilled adversary might be able to intercept the mail + in transit, but if you're using StartTLS, that's already encrypted in transit. diff --git a/docs/howto/operation/staffing.md b/docs/howto/operation/staffing.md new file mode 100644 index 0000000..68fc05d --- /dev/null +++ b/docs/howto/operation/staffing.md @@ -0,0 +1,174 @@ +# CVD Staffing Considerations + +Staffing a CVD capability requires a mix of technical and soft skills. +The roles and responsibilities of a CVD team can vary depending on the +size of the organization, the volume of incoming reports, and the +organization's existing security posture. +Here we primarily focus on two specific issues related to maintaining a +healthy and effective CVD team: + +- Skills development and training +- Avoiding analyst burnout + +## Skills Development and Training + +Vulnerability analysis and response may require networking and forensics +skills for certain classes of vulnerabilities, but often also requires +some mix of the following skills: + +
+ +- **Technical Skills** + + - Programming skills, especially in common languages (C, C++, Python, Java) + - Reverse engineering and debugging + - Knowledge of low-level operating system features for Windows, Mac and/or Linux + - Software security testing + - Virtualization, containers, and some infrastructure automation + - Knowledge of common vulnerabilities and exploits + - (specialized) Hardware architecture and basic electrical engineering + - (emerging) Knowledge of machine learning and AI + +- **Soft Skills** + + - Curiosity and a desire to understand how things work + - Interest in learning new technologies + - Clear and concise written communications + - Customer-service mindset + - Ability to work under pressure + - Ability to communicate with non-technical stakeholders + - Ability to communicate with technical stakeholders + +
+ +In most organizations, these skills will likely be dispersed among a +team of people rather than expecting a single person to be fluent with +all of these topics. + +!!! info "FIRST CSIRT Services Framework" + + The FIRST [CSIRT Services Framework](https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1) + addresses staffing considerations throughout, but we'll highlight a few items from _9 Service Area: Knowledge Transfer_: + + | Function | Purpose | Outcome | + |----------|---------|---------| + | 9.2.4 Mentoring | Develop a program for CSIRT staff, constituency members, or external trusted partners to learn from experienced staff through an established relationship. | Developed and trained staff are available with the requisite technical and soft skills and process understanding, and who are up to date based on the job roles and needs. | + | 9.2.5 CSIRT staff professional development | Help staff members successfully and appropriately plan and develop their careers. | Developed and trained staff are available with the requisite technical and soft skills and process understanding, and who are up to date based on the job roles and needs. | + +!!! info "FIRST PSIRT Services Framework" + + Even closer to the CVD process, the FIRST [PSIRT Services Framework](https://www.first.org/standards/frameworks/psirts/psirt_services_framework_v1.1) + also addresses staffing considerations in multiple sections, but here we'd like to highlight _Service 6.1 Training the PSIRT_ + + | Function | Purpose | Outcome | + |----------|---------|---------| + | 6.1.1 Technical training | Train the PSIRT Staff so that they understand the issue that is being reported and can adequately perform the initial triage before handing it off to teams responsible for developing, testing, and releasing fixes. | PSIRT Staff has sufficient technical training to perform their duties. | + | 6.1.2 Communications Training | Ensure PSIRT Staff follows the communication policies of the organization while interacting with external entities thus eliminating any regulatory/legal issues that may result from improper communication. | PSIRT Staff will have sufficient communications training to perform their assigned duties with clear accuracy and no ambiguity in communications. | + | 6.1.3 Process Training | Ensure there is a smooth flow of information in managing product security incidents which will result in timely resolution of issues. | PSIRT Staff will be sufficiently trained on internal processes so that they can perform their duties. | + | 6.1.4 Tools Training | Identify tools to track the third-party components embedded in products so the vulnerabilities can be tracked and released in these components. | PSIRT Staff will have an understanding and be able to track third-party components within shipped products. | + +## Beware Analyst Burnout + +!!! info inline end "Security Analyst Burnout Articles" + + There are many articles and studies on the topic of security analyst burnout. Here are a few: + + - [It’s Time to Break the SOC Analyst Burnout Cycle](https://www.sans.org/blog/it-s-time-to-break-the-soc-analyst-burnout-cycle/) + - [Defending the Defenders: Understanding and Preventing Security Analyst Burnout](https://www.bitdefender.com/blog/businessinsights/defending-the-defenders-understanding-and-preventing-security-analyst-burnout/) + - [Building a Security Operations Center (SOC)](https://www.rsaconference.com/events/us12/agenda/sessions/683/building-a-security-operations-center-soc) + - [Avoiding burnout: Ten tips for hackers working incident response](http://www.csoonline.com/article/2149900/infosec-careers/avoiding-burnout-ten-tips-for-hackers-working-incident-response.html) + - [A human capital model for mitigating security analyst burnout](https://www.usenix.org/conference/soups2015/proceedings/presentation/sundaramurthy) + +Some organizations may have a small enough flow of incoming +vulnerability reports that all the CVD-related roles can be fulfilled by +a single team, or even a single person. Other organizations might choose +to split the technical analysis roles apart from the more human-oriented +communication and coordination roles. No matter the arrangements, it is +important that vendors and coordinators establishing a CVD capability +mitigate the potential for analyst burnout. Burnout of security analysts +is well-documented phenomenon (see inset at right). Analysts working full-time in a +CVD process are at risk of this too. + +A vendor's CVD capability may +receive a large amount of incoming reports each week, especially at +larger vendors. This can result in CVD staff becoming stressed and +having low job satisfaction, leading to lower quality of work and +ultimately employee attrition. The costs of lower quality work (e.g., +missing an important report), employee turnover (e.g., hiring and +training a new analyst), and associated damage to the vendor's +reputation suggest that this problem should be addressed ahead of time +with reasonable precautions. +At the CERT/CC, we have attempted to +mitigate this issue with reasonable success by implementing the +suggestions below. +[Research](https://www.usenix.org/conference/soups2015/proceedings/presentation/sundaramurthy) has shown that many of +these are effective responses to commonly-held morale problems. + +
+ +!!! tip "Reserve Capacity" + + Organizations + may choose to have several team members, trained in the CVD process + and tools, who can temporarily assist should a regular CVD analyst + be unavailable for any reason, even if these additional team members + do not typically do CVD day-to-day. Of course, handing off reports + between temporary and full-time analysts leads to other operational + concerns as previously discussed, so this must be done carefully. + Organizations must also take care that these temporary team members + are not pulled away from their own work so often that they + themselves experience burnout. + +!!! tip "Rotate Roles" + + A related possibility shared with us by a vendor is the possibility of + *work rotation,* whereby team members are rotated in and out of CVD + roles; rather than temporary, the rotation is permanent among a larger + group of team members. An example would be an analyst spending one week + in a CVD role, followed by two to three weeks on a different project or + role. The same concerns in our prior discussion would apply; + organizations must be careful to balance time in and out of CVD roles in + order to maximize the effectiveness of the rotation. + +!!! tip "Allow analyst independence" + + Generally, you should trust your + analysts to make good decisions during the report prioritization process, + and empower them to make CVD decisions. Allowing analyst autonomy + with management's specific blessing provides relief to analysts + attempting to prioritize reports. Many reports will be incomplete, + inaccurate, unimportant, or not actionable; allowing analysts to + make the judgment on which reports deserve priority and which should + be closed may help reduce work-related stress. + +!!! tip "Allot professional development time" + + Analysts schedule some + time each week to focus on professional development or projects. + During these times, the analyst is not expected to perform CVD + duties. Providing this time in whole-day chunks is preferable to + spreading it out across the week. It is also important that during + these days the analyst not be disturbed; urgent tasks should be + handled by other on-duty analysts as much as possible. This + suggestion may be combined with work rotation to allow for regular + project work outside of the scope of CVD. + +!!! tip "Seek out automation" + + We have encouraged analysts to document + procedures and processes that need updating or could even be + automated. Prototypes can be implemented and rolled out to decrease + the cognitive workload of analysts. Processes and tools should be + reviewed regularly to ensure they are aiding the analyst, rather + than fighting the analyst. + +!!! tip "Well-Resourced Teams for CVD" + + Due to the possibility of burnout and the associated costs, the CERT/CC + recommends that CVD capability be established within a well-resourced + team or teams specifically created for this task, rather than + concentrating the responsibilities to a small team, or even a single + person. Our suggestions above may be helpful to combat analyst burnout, + but do not form an exhaustive list of possible actions. + +
diff --git a/docs/howto/operation/technical_analysis.md b/docs/howto/operation/technical_analysis.md new file mode 100644 index 0000000..3d2b3a1 --- /dev/null +++ b/docs/howto/operation/technical_analysis.md @@ -0,0 +1,109 @@ +# Technical Analysis + +While some CVD participants primarily collect, collate, and relay reports, others have the capability to perform +deeper technical analysis. +In [Phases](../../topics/phases/index.md), we make a distinction between report [validation](../../topics/phases/validation.md) +and deeper analysis leading to problem isolation and remediation ([Remediation](../../topics/phases/remediation.md)). + +!!! tip "Depth of Analysis" + + The depth of analysis required will depend on the organization's capabilities and the nature of the vulnerability. + For basic report validation, an organization might only need to be able to judge report credibility, set up test environments, and test scenarios appropriate to the report. + + Deeper analysis might involve: + + - Test case development and refinement + - Instrumentation and debugging + - Source code analysis + - Static binary code analysis (reverse engineering) + - Dynamic code analysis + - Root cause analysis + +## Test Environments + +Having an internal testing infrastructure is vital to proper prioritization +and resolution of vulnerability reports as we discussed in +[Validation](../../topics/phases/validation.md) and [Prioritization](../../topics/phases/prioritization.md). +Be sure your analysts have proper access to any necessary software +needed for testing. This includes maintaining appropriate software +licenses for proprietary software, although in many cases free and/or +open source alternatives are available. + +!!! tip "Toolkits" + + Analysts should have access to a toolkit of software to assist in + their analysis. The contents of such a toolkit will vary depending on + the organization's needs and capabilities. + Toolkits often include the + following: + + - Container or virtualization platform, often a need to support multiple operating + systems + - Debuggers + - Source code analysis tools + - Binary analysis tools (decompilers, etc.) + - Network sniffing tools + - Hex editors + - Text editors + - Visualization (often built into other tools) + + Vendors with more hardware-centric products may need to additionally + maintain more physical gear or specialized test bench equipment in order + to have sufficient capacity to confirm reports. + +
+ +!!! tip "Virtualization and Cloud Infrastructure" + + By far the easiest way to build a vulnerability testing infrastructure + is the use of virtualization technologies. Many different virtual + machine environments can be built for receivers of vulnerability reports + to verify or clarify the reports they receive. + Containers are another useful option, but they are generally less isolated than + virtual machines and may not be appropriate for all testing scenarios. + +!!! tip "Dedicated Testing Resources" + + Not everything can be tested in a virtual environment, however. Some + vulnerabilities are hardware-specific, or require specialized + equipment to test. In these cases, it may be necessary to maintain a + physical test bench. + +
+ +!!! example "CERT/CC's Testing Infrastructure" + + At the CERT/CC, we maintain a firewalled testing network in which + virtual machines can be placed for testing. We also maintain a few + permanent pre-configured servers on this network (HTTP web servers, + etc.) to allow easy testing of certain classes of vulnerabilities, such + as "drive-by" browser downloads. Much of this infrastructure could be + replicated entirely in a virtual network within a single machine, or in + a cloud-based environment if desired. + +## Tool Development + +In some cases, it may be necessary to develop new tools to assist in +vulnerability analysis. This can be a significant investment of time and +resources, but can also pay off in the long run by making the analysis +process more efficient. + +
+!!! tip "Vulnerability Report Analysis can Boost Internal Discovery" + + Not only is testing useful for confirming reports, or reproducing and isolating bugs; it can + also serve as a platform for an organization to develop its own + vulnerability discovery capability. + The analysts responsible for confirming incoming reports will, over time, + develop a familiarity with the ways in which a product is vulnerable, + and, given appropriate training and support, can begin to apply this + knowledge directly to the product without having to wait for + vulnerability reports to arrive from elsewhere. + +!!! example "Testing Infrastructure and Tool Development" + + We have followed this exact path at the CERT/CC: tools such as [Dranzer](https://github.com/CERTCC/dranzer) and + [BFF](https://github.com/CERTCC/certfuzz) came directly out of vulnerability analysts applying broad knowledge of + vulnerabilities gained from detailed analysis of reports toward the development of automated discovery processes. + +
diff --git a/docs/howto/preparation/avoid_risk.md b/docs/howto/preparation/avoid_risk.md new file mode 100644 index 0000000..af17ddb --- /dev/null +++ b/docs/howto/preparation/avoid_risk.md @@ -0,0 +1,106 @@ +# Avoid Unnecessary Risk in Finding Vulnerabilities + +Looking for vulnerabilities in software and hardware is a critical part of +the security ecosystem. However, it is important to do so in a way that +minimizes the potential for harm to others. +This section provides advice for +finders and vendors on how to avoid unnecessary risk when finding +vulnerabilities. + +
+ +!!! tip "Advice for Finders" + + Finders should exercise an appropriate degree of care when performing + vulnerability research. This will help to alleviate legal concerns and + limit the potential for damage to others. + Vulnerability research should of course be performed on equipment that + the finder is authorized to use for the purpose. If the research is + performed on behalf of an organization such as a private security firm + or university, permission should be obtained before attempting research + on organization-owned equipment. + +!!! tip "Advice for Vendors" + + Likewise, organizations should make the rules and process for obtaining + permission very clear and easy to find. For example, a form or email + address provided on an intranet page might be sufficient. Employees + hired specifically to find vulnerabilities should be briefed on + necessary rules and provided with concrete permission as part of the + on-boarding process. Failure to adequately document permissible scope + and authority for vulnerability testing can lead to frustration and + other negative consequences with various legal ramifications. + +
+ +## Types of Risk + +There are several types of risk that should be considered when +performing vulnerability research. These include operational risk, +safety risk, and legal risk. + +
+ +!!! warning "Operational Risk" + + In general, the software or devices tested should not be production + systems that support or have access to real data or users. When + possible, dedicated, controlled testing environments should be + established. Such a testing environment often consists of virtual + machines (VMs) in a virtual network firewalled off from any production + network. Even as a finder in a controlled testing scenario, you should + keep in mind the potential for unintended consequences (i.e., the + unknown unknowns). Always try to limit the potential for unintended + negative impact of testing, even within your controlled environment. If + the impact cannot be constrained to a controlled environment with + relatively known consequences, do not attempt to test your exploit and + instead report your findings directly to the vendor. + +!!! warning "Safety Risk" + + [Safety-critical systems](https://ieeexplore.ieee.org/document/1007998) + have been defined as "systems whose failure + could result in loss of life, significant property damage, or damage to + the environment." A high degree of caution is both appropriate + and necessary when testing the security of safety-critical systems, such + as medical devices, industrial equipment, or vehicles. A proof of + concept exploit to demonstrate a vulnerability on a traditional computer + might cause a calculator to pop up on the screen. A proof of concept + exploit on a car might cause it to behave erratically, potentially + leading to injury or death. Testing or demonstrating safety-critical + systems outside a controlled environment, or when there is any chance of + harming unwitting bystanders is unacceptable under any + circumstances. + +
+ +!!! warning "Legal Risk" + + Depending on the circumstances, finders may be subject to a + non-disclosure agreement (NDA) regarding any vulnerabilities found. This + is often the case when vulnerability testing is performed on behalf the + vendor whether directly as an employee, or under contract as part of a + consulting firm or as a freelance consultant. Finders should be aware of + this possibility and consider the legal implications of any relevant + NDAs before reporting a vulnerability to any third party. + + That said, vendors are strongly encouraged to avoid requiring NDAs of + reporters if at all possible. Many finders prefer to avoid the legal + entanglements that NDAs entail and will be discouraged from reporting + vulnerabilities when an NDA is involved. This can leave vendors unaware + of potential threats to their products and services and in turn, their + users. + + Additionally, in some environments, such as medical devices, healthcare, + education, or financial information systems, there may be legal + consequences to accessing real data (under + [HIPAA](https://www.hhs.gov/hipaa/), + [FERPA](https://ed.gov/policy/gen/guid/fpco/ferpa/index.html), + [COPPA](https://www.ftc.gov/enforcement/rules/rulemaking-regulatory-reform-proceedings/childrens-online-privacy-protection-rule), + and similar laws, industry standards such as [PCI DSS](https://www.pcisecuritystandards.org/pci_security/), + etc.), so we again reiterate the need to perform research only in + controlled test environments, preferably with fake data. + + For more information on the legal implications of vulnerability + disclosure, we refer you to the [*EFF's Coders' Rights Project + Vulnerability Reporting FAQ*](https://www.eff.org/issues/coders/vulnerability-reporting-faq). diff --git a/docs/howto/preparation/choosing_policy.md b/docs/howto/preparation/choosing_policy.md new file mode 100644 index 0000000..820d8bc --- /dev/null +++ b/docs/howto/preparation/choosing_policy.md @@ -0,0 +1,56 @@ +# Choosing a Disclosure Policy + +For those responsible for implementing the CVD process, defining a +disclosure policy is an important first step. +A well-defined policy +makes it clear what other participants in the CVD process can expect +when they engage with you and establishes good relationships between +finders, reporters, vendors, coordinators, and other stakeholders. + +A disclosure policy typically describes what CVD stakeholders (finders, +reporters, vendors, coordinators) can expect in terms of these factors: + +- **Scope** -- A description of the scope of issues to which the + policy applies. This scope should be as explicit as possible, + especially when there are specific boundaries of concern to the + organization. If a bounty is to be paid for some classes of + vulnerability reports, the scope definition should clearly delineate + which kinds of reports will be eligible for the bounty. + +- **Exceptions** -- Any exceptional conditions that may alter the + typical flow of the process + +- **Safe Harbor** -- Should your organization choose to explicitly + disavow legal retribution against reporters who otherwise follow the + policy, that fact should be clearly laid out in the policy document. + +- **Report quality requirements** -- It's okay to require reports to + meet a certain level of quality before committing to taking action + on them. However, it's also useful to judiciously apply the + [principle of robustness](https://datatracker.ietf.org/doc/rfc760/) + here: "In general, an implementation should be conservative in its sending behavior, + and liberal in its receiving behavior." + +- **Preferred Communication Language(s)** -- If the organization has + preferences for specific (human) languages for reports, the policy + should specify this. That said, English is usually acceptable as a + default. + +- **Contact Information** -- How should reports be submitted? How can + you be reached? + +- **Timing** -- Setting expectations for response timelines of the + various milestones in a vulnerability report case can be helpful + too. Most important are expected time to acknowledge receipt of a + report and a default disclosure timeframe if one has been defined. + An acknowledgement timeframe of 24-48 hours is common for vendors + and coordinators, while 45-90 days seems to be the normal range for + public disclosures these days. That said, we recommend that both vendors + and reporters treat policy-declared disclosure timeframes as the + starting point of a negotiation process rather than a hard deadline. + +{% include-markdown "../../_includes/_certcc_policy_tip.md" heading-offset=1 %} + +!!! info "Disclosure Policy Templates" + + {% include-markdown "../../reference/disclosure_policy_templates.md" heading-offset=1 start="" end="" %} diff --git a/docs/howto/preparation/disclosure_choices.md b/docs/howto/preparation/disclosure_choices.md new file mode 100644 index 0000000..eafb572 --- /dev/null +++ b/docs/howto/preparation/disclosure_choices.md @@ -0,0 +1,80 @@ +# Disclosure Choices + +As we have mentioned previously, participants in Coordinated +Vulnerability Disclosure iterate over the following questions: + +{% include-markdown "../../_includes/_core_questions_of_cvd.md" %} + +Let's take a moment to explore questions 2 and 3 in a few scenarios. +There are several options for how to disclose a vulnerability. +Each of these disclosure options have advantages and disadvantages. +In this section, we adapt and expand some terminology from Shepherd +[^1]. + +
+ +!!! info "No Disclosure" + + All information about the vulnerability is kept private. Sometimes + this is enforced by non-disclosure agreements (NDAs). Vendors + sometimes prefer this scenario to protect trade secrets or to lessen + the impact of perceived negative press. Some finders prefer not to + disclose vulnerabilities to anyone, in the hope that malicious actors + will not find out about the vulnerability if it is not disclosed. Data + on the outcomes of a non-disclosure policy are difficult to come by, + as these vulnerabilities are by definition hidden from public view. + +!!! info "Private Disclosure" + + When a product's vendor is aware of a + vulnerability, the vendor may take action to address it but will + only notify its own customer base of the vulnerability and its + mitigation privately. Many of the same motives as the No Disclosure + policy are also in play here; the hope is that malicious actors are + much less likely to find out about and exploit a vulnerability if + very few people are made aware of the issue. Avoiding negative press + is also cited as a reason for this approach. Some vulnerability + finders are satisfied by this method if all known customers can be + reached, so that everyone using the software may be protected. + However, this approach is often not practical for widely deployed or + open source software. + +!!! info "Limited (Partial) Disclosure" + + When a vulnerability is found, + only some information about the vulnerability is disclosed to the + public. The goal is typically to slow down reverse engineering and + exploit development long enough for a fix to be developed and + deployed. This is done by withholding proof of concept code or other + technical details of the vulnerability while still providing enough + information that users of the product may take action to mitigate + the issue. + +!!! info "Full Disclosure" + + When a vulnerability is found, all + information about the vulnerability is disclosed to the public. + Typically, this scenario results in the release of proof of concept + exploit code along with a report describing the vulnerability. In + some cases, finders following a full disclosure approach may not + attempt to notify the vendor at all in advance of the public release + of the vulnerability report. In other cases, they may contact the + vendor simultaneously or shortly before issuing a public report. The + belief is that this approach serves the greater good by allowing + consumers to be aware of the full impact of issues in their products + and demand action from vendors, as well as have information + available to take appropriate defensive action and make more + informed purchasing decisions. Another perceived benefit is that a + full disclosure allows other researchers and organizations to + reproduce and confirm the vulnerability, whereas a more limited + disclosure may not provide enough information to do so. Alternately, + this type of disclosure may also be performed by the vendors + themselves: many open source projects, for example, handle security + issues in the open in order to maximize review of the vulnerability + and testing of the proposed solution. + +
+ +[^1]: S. Shepherd, "Vulnerability Disclosure: How Do We Define + Responsible Disclosure?" SANS GIAC SEC Practical Repository, + 2003. diff --git a/docs/howto/preparation/index.md b/docs/howto/preparation/index.md new file mode 100644 index 0000000..df403bc --- /dev/null +++ b/docs/howto/preparation/index.md @@ -0,0 +1,35 @@ +# Preparation for Coordinating Vulnerability Disclosure + +Whether you're a security researcher, a vendor, or a coordinator, +there are a few things you can do to prepare for a CVD process. +This section provides some general advice on how to get ready for a CVD process, +and how to make sure you're in a good position to handle any issues that might arise. + +
+ +- :material-checkbox-multiple-marked-circle-outline: [Disclosure Choices](disclosure_choices.md) + + --- + {% include-markdown "./disclosure_choices.md" start="" end="" %} + +- :material-head-question: [Why Coordinate?](why_coordinate.md) + + --- + {% include-markdown "./why_coordinate.md" start="" end="" %} + +- :material-railroad-light: [Avoid Unnecessary Risk](avoid_risk.md) + + --- + {% include-markdown "./avoid_risk.md" start="" end="" %} + +- :octicons-checklist-16: [Choosing a Disclosure Policy](choosing_policy.md) + + --- + {% include-markdown "./choosing_policy.md" start="" end="" %} + +- :material-graph: [Communication Topology](topology.md) + + --- + {% include-markdown "./topology.md" start="" end="" %} + +
diff --git a/docs/howto/preparation/topology.md b/docs/howto/preparation/topology.md new file mode 100644 index 0000000..d83c34b --- /dev/null +++ b/docs/howto/preparation/topology.md @@ -0,0 +1,187 @@ +# Communication Topology + +!!! example inline end "Pairwise Communication Complexity" + + Graph theory tells us the number of participant pairs increases as $(N^2 - N)/2$ for $N$ + participants. So while there are only 10 pairs for 5 participants, there are 45 pairs for 10 participants. + +The complexity of coordination problems increases rapidly as more +parties are involved in the coordination effort. +As a result, multiparty coordination using point-to-point +communications do not scale well. +Borrowing from communication network +concepts, multiparty coordination involving more than a few participants +can be improved with a shift to either a hub-and-spoke or shared-bus +topology in lieu of a full mesh or collection of point-to-point +communications. + +
+ +```mermaid +--- +title: Full Mesh +--- +flowchart LR + a(( )) + b(( )) + c(( )) + d(( )) + e(( )) + a --- b + a --- c + a --- d + a --- e + b --- c + b --- d + b --- e + c --- d + c --- e + d --- e +``` + +```mermaid +--- +title: Hub and Spoke +--- +flowchart LR + a(( )) + b(( )) + c(( )) + d(( )) + e(( )) + a --- b + b --- c + b --- d + b --- e +``` + +```mermaid +--- +title: Point to Point +--- +flowchart LR + a(( )) + b(( )) + c(( )) + d(( )) + e(( )) + a --- b + a --- c + b --- c + c --- d + d --- e + +``` + +```mermaid +--- +title: Shared Bus +--- +flowchart TD + a(( )) + + b(( )) + c(( )) + d(( )) + e(( )) + shared([shared
channel]) + a --- shared + b --- shared + c --- shared + d --- shared + e --- shared +``` + +
+ +## The Evolution of CERT/CC CVD Topology + +In the past, the CERT/CC took a hub-and-spoke approach to coordination +for cases where it was feasible to maintain separate conversations with +the affected parties. Maintaining a hub-and-spoke +coordination topology for each distinct case requires some forethought +into tools and practices, though—you can't just carbon-copy +everybody, and without good tracking tools, keeping tabs on who knows +what can be difficult. A hub-and-spoke topology allows a coordinator to +maintain operational security since each conversation has only two +participants: the coordinator and the other party. The tradeoff is that +the coordinator (hub) can easily become a bottleneck during especially +active coordination situations. + +Over time, we recognized that the hub-and-spoke approach was not +scaling to meet the needs of the increasing number of participants in +some coordination efforts. +Even as early as the early 2000s, some of the larger coordination efforts we encountered +required more of a shared-bus approach through the use of conference +calls, group meetings, and private mailing lists. This approach puts the +CVD participants in direct contact with each other rather than having a +coordinator acting as a proxy for all communications while minimizing +the communication overhead. A shared-bus approach can increase the +efficiency of communications, but can on occasion make it harder to +reach agreement on what is to be done. + +### Today: VINCE + +!!! info inline end "More about VINCE" + + For more information about the _Vulnerability Information and Coordination Environment_ (VINCE), + see: + + - [VINCE Announcement](https://insights.sei.cmu.edu/news/certcc-releases-vince-software-vulnerability-collaboration-platform/) + - [VINCE Documentation](https://vuls.cert.org/confluence/display/VIN) + - [VINCE GitHub Project](https://github.com/CERTCC/VINCE) + - [VINCE Login](https://www.kb.cert.org/vince) + +More recently, however, with the +[introduction](https://insights.sei.cmu.edu/news/certcc-releases-vince-software-vulnerability-collaboration-platform/) +of the +[Vulnerability Information and Coordination Environment](https://www.kb.cert.org/vince) +(VINCE), we have adopted the shared-bus approach as our default. +VINCE is a web-based platform that allows for the sharing of information +among multiple parties in a secure environment. +For each new vulnerability, CERT/CC creates a VINCE case discussion, +which is a private message-board forum complete with the abilities to tag +other participants, upload files, and send CERT/CC private messages. +CERT/CC then invites reporters, researchers, and vendors related to the +vulnerability to join the case discussion. To participate, stakeholders +must have a VINCE account, and they can ask CERT/CC to add them to a case +discussion. CERT/CC continues to coordinate and moderate each case, +but the stakeholders can work directly with each other, both before and +after any public disclosure of the vulnerability. + +While VINCE has been a significant improvement in our ability to +coordinate multiparty CVD efforts, it is not a panacea. +For example, it is not always possible to get all stakeholders to +participate in a VINCE case discussion. It is also a single point of +failure, and if it goes down, we lose the ability to coordinate +effectively. + +### Tomorrow: Vultron + +!!! vultron inline end "More about Vultron" + + For more information about the _Vultron Protocol_, see: + + - [Vultron Announcement](https://insights.sei.cmu.edu/blog/vultron-a-protocol-for-coordinated-vulnerability-disclosure/) + - [Vultron Documentation](https://certcc.github.io/Vultron) + - [Vultron GitHub Project](https://github.com/CERTCC/Vultron) + +In response to these limitations, we have embarked on a project to develop +an open protocol for coordinating and sharing vulnerability case information across organizations. +This project, called the [Vultron Protocol](https://certcc.github.io/Vultron), +is a research project to explore the creation of a federated, decentralized, +and open source protocol for coordinated vulnerability disclosure (CVD). + +Our goal is to provide a protocol that can be used by any organization to coordinate the disclosure of vulnerabilities +in information processing systems (software, hardware, services, etc.), and to build a community of interoperability +across independent organizations, processes, and policies that can work together to coordinate appropriate responses +to vulnerabilities. +Whereas VINCE is a platform, Vultron is a protocol. + +!!! question "What is the difference between a platform and a protocol?" + + A platform is a set of tools and services that are provided by a single entity, while a protocol is a set of + rules that allow multiple entities to communicate and coordinate with each other. + VINCE is a platform that provides a set of tools and services for coordinating vulnerability disclosure, + while Vultron is a protocol that provides a set of rules for how organizations can communicate and coordinate + with each other in a decentralized and federated manner. diff --git a/docs/howto/preparation/why_coordinate.md b/docs/howto/preparation/why_coordinate.md new file mode 100644 index 0000000..e1f68aa --- /dev/null +++ b/docs/howto/preparation/why_coordinate.md @@ -0,0 +1,102 @@ +# Why Coordinate Vulnerability Disclosures? + +Vulnerability disclosures fall between two extremes: + +```mermaid +flowchart LR + full(Tell everyone
everything you know
about a vulnerability
as soon as you know it) + cvd([Vulnerability
Disclosure]) + never(Tell no one
anything you know
about a vulnerability
ever) + full <--> cvd + cvd <--> never +``` + +Prior research at Carnegie Mellon into [vulnerability disclosure practices](https://doi.org/10.1007/s10796-006-9012-5) has shown +that neither extreme is socially optimal. Thus, we are given to hope +that we can improve on these extremes by striking a balance in between. +But doing so requires several questions to be answered: + +!!! question "Questions to Answer in CVD" + + - How much information should be released? + - To whom? + - When? + - Do you wait for a patch to be deployed before announcing the vulnerability's existence? + - Do you wait for the patch to be available but not yet deployed? + - Is it okay to acknowledge that you know of a vulnerability in a product without providing any other details? + +It's also important to consider that not all factors are within control +of the parties involved in the disclosure process. Adversaries can +discover vulnerabilities and use them to exploit vulnerable systems +regardless of your participation in a well-coordinated disclosure +process. And yet many vulnerabilities might never be exploited in +attacks. So how should we approach the question of potential harm and +the questions surrounding risk and reward of vulnerability disclosure? + +!!! question inline end "Isn't it better to keep vulnerabilities secret?" + + Some vendors express concern about the negative attention brought by + having a long list of publicly disclosed vulnerabilities in their + products. In our opinion, the number of vulnerabilities found in a + vendor's products is less valuable as an indicator of the vendor's + security stance than the consistency of its response to vulnerabilities + in a comprehensive and timely manner. In the end, the goal of CVD is to + help users make more informed decisions about actions they can take to + secure their systems. + +The CERT/CC believes the Coordinated Vulnerability Disclosure (CVD) +process provides a reasonable balance of these competing interests. +The +public and especially users of vulnerable products deserve to be +informed about issues with those products and how the vendor handles +those issues. At the same time, disclosing such information without +review and mitigation only opens the public up to exploitation. The +ideal scenario occurs when everyone coordinates and cooperates to +protect the public. +This coordination may also be turned into a public +relations win for the vendor by quickly addressing the issue, thereby +avoiding bad press for being unprepared. + +!!! info "FIRST's Vulnerability Coordination Special Interest Group" + + The [Forum of Incident Response and Security Teams](https://www.first.org) (FIRST), + which consists of many public and private organizations and companies involved + in vulnerability and security incident handling, has established a + [Vulnerability Coordination Special Interest Group](https://www.first.org/global/sigs/vulnerability-coordination) + to develop some common + CVD best practices and guidelines. While the existence of + individual vulnerabilities may be unexpected and surprising, these + common practices should help lead to fewer surprises for all + stakeholders in the CVD process itself. + +!!! info "CVD is Recognized by Governments and International Organizations" + + Governments and international organizations also recognize the need for coordinated vulnerability disclosure practices. + Just to name two examples: + + In 2015, the Department of Commerce's National Telecommunications and Information Administration initiated a + [Multistakeholder Process for Cybersecurity Vulnerabilities](https://www.ntia.doc.gov/other-publication/2016/multistakeholder-process-cybersecurity-vulnerabilities) to + + > develop a broad, shared understanding of the overlapping interests + > between security researchers and the vendors and owners of products + > discovered to be vulnerable, and to establish a consensus about + > voluntary principles to promote better collaboration. The question of + > how vulnerabilities can and should be disclosed will be a critical + > part of the discussion, as will how vendors receive and respond to + > this information. However, disclosure is only one aspect of successful + > collaboration. + + In 2023, the [European Union Agency for Cybersecurity](https://www.enisa.europa.eu/) + published a [report on Coordinated Vulnerability Disclosure](https://www.enisa.europa.eu/news/coordinated-vulnerability-disclosure-towards-a-common-eu-approach) + + > With the new Directive on measures for a high common level of cybersecurity across the Union (NIS2) adopted on + > 16 January 2023, Member States will need to have a coordinated vulnerability disclosure policy adopted and + > published by 17 October 2024. In addition, other ongoing legislative developments will also address vulnerability + > disclosure, with vulnerability handling requirements already foreseen in the proposed Cyber Resilience Act (CRA). + > The new report published today looks into the expectations of both industry and the Member States in relation to + > the NIS2’s objective. It also analyses the related legal, collaborative, technical challenges arising from such + > initiatives. + + attack frequency increase with vulnerability disclosure? An + empirical analysis," *Information Systems Frontiers,* vol. 8, no. + 5, pp. 350-362, 2006. diff --git a/docs/howto/recipes/_recipe_explainer.md b/docs/howto/recipes/_recipe_explainer.md new file mode 100644 index 0000000..d9f5028 --- /dev/null +++ b/docs/howto/recipes/_recipe_explainer.md @@ -0,0 +1,14 @@ +!!! info "CVD Recipe Cards" + + !!! info inline end "" + + Like a recipe card, each item includes an _ingredients_ list that describes + + - the _roles_ affected + - the _phases_ in which the problem is likely to arise + - the _problem_ itself + + In this edition of the Guide, we have organized our problem solving advice into a set of recipe cards. + + The _recipe_ portion of each card provides a set of instructions for resolving the problem. + These aren't necessarily step-by-step instructions, but rather a set of guidelines to help you navigate the problem. diff --git a/docs/howto/recipes/_x01.md b/docs/howto/recipes/_x01.md new file mode 100644 index 0000000..a069eb4 --- /dev/null +++ b/docs/howto/recipes/_x01.md @@ -0,0 +1,19 @@ + +!!! warning "Finder does not have the resources to shepherd a CVD case through to resolution" + + !!! warning inline end "" + + **Role(s) affected:** Finder + + **Phase(s):** Discovery, Reporting, Validation and prioritization, Remediation, Public Awareness + + **Description:** + + 1. The vulnerability was found + 2. The finder / reporter is unable to devote the necessary resources (time, effort, etc.) to following it through to resolution + + - Choosing to participate in Coordinated Vulnerability Disclosure can set into motion a protracted series of events which many finders and reporters may find exceeds their ability to sustain. The short answer is that you don't have to. + - Our experience is that many vendors are happy to receive reports even if the reporter disengages from the process immediately thereafter. The reporter's degree of involvement can therefore be self-regulating. + - We also remind our readers that Finders do not have to be reporters at all. We are unaware of any requirement for finders to report any vulnerabilities directly to the affected vendors. + - Finders that are genuinely indifferent to the effects of "dropping 0-day" always remain free to do so. (Although this likely impacts vendors' propensity to cooperate with them in the future.) Nonetheless going public with a vulnerability can be valid choice on the part of the finder. It's often informative if they also share their reason for doing so. + - For finders that want to be reporters but not manage the process, third party coordinators can sometimes offload some of the effort required. diff --git a/docs/howto/recipes/_x02.md b/docs/howto/recipes/_x02.md new file mode 100644 index 0000000..4c25355 --- /dev/null +++ b/docs/howto/recipes/_x02.md @@ -0,0 +1,19 @@ + +!!! warning "Evidence of exploitation for an embargoed report" + + !!! warning inline end "" + + **Role(s) affected:** Reporter + + **Phase(s):** Reporting, Validation and prioritization, Remediation + + **Description:** + + 1. The vulnerability is still under embargo (i.e., the process has not reached the Public Awareness phase yet). + 2. Evidence indicates that the vulnerability is being used by attackers. + + - At this point, the embargo is effectively moot, and the Public Awareness phase has been entered regardless of whether the preceding phases have completed. + - Vendors, Coordinators, and Reporters should always be ready to immediately terminate an embargo and go public with whatever advice is available at the time that evidence of exploitation becomes known. + - The Vendor should accelerate their remediation development as much as possible. + - Even a simple Vendor acknowledgement that the problem is being worked on can help deployers adjust their response accordingly. + - See [Active Exploitation](../coordination/active_exploitation.md) for more information on this topic. diff --git a/docs/howto/recipes/_x03.md b/docs/howto/recipes/_x03.md new file mode 100644 index 0000000..d8f3461 --- /dev/null +++ b/docs/howto/recipes/_x03.md @@ -0,0 +1,20 @@ + +!!! warning "Unable to engage vendor contact" + + !!! warning inline end "" + + **Role(s) affected:** Reporter + + **Phase(s):** Reporting + + **Description:** + + 1. The reporter wishes to report a vulnerability to the vendor + 2. The reporter has been unable to find a way to contact the vendor + + - Assuming the reporter chooses to continue pursuing the issue at all, their options include: + + - The reporter may publish the report on their own. Hard-to-reach vendors often become less so after a vulnerability or two is made public without their involvement. + - The reporter may attempt to engage a coordinator, to continue trying to reach the vendor + + - See [Find Vendor Contact](../initiation/find_vendor_contact.md), [Reporting](../../topics/phases/reporting.md) and [Unresponsive Vendor](../initiation/unresponsive_vendor.md). diff --git a/docs/howto/recipes/_x04.md b/docs/howto/recipes/_x04.md new file mode 100644 index 0000000..1111abd --- /dev/null +++ b/docs/howto/recipes/_x04.md @@ -0,0 +1,20 @@ + +!!! warning "Vendor does not have a posted bug bounty" + + !!! warning inline end "" + + **Role(s) affected:** Reporter + + **Phase(s):** Reporting + + **Description:** + + 1. The reporter wishes to report a vulnerability to the vendor + 2. The vendor does not have a public bug bounty + 3. The reporter asks the vendor if they have a bug bounty + 4. The vendor responds non-constructively + + - Up until a few years ago, bug bounties were rare. Today, vendors that intend to pay bounties for vulnerability reports have taken positive action to communicate this fact to finders and reporters. They will usually have clearly defined communication channels, program scopes, etc. posted in easily found locations. + - By extension, a vendor that has not taken such action has either chosen not to, or may be entirely novice to the practice of CVD. If they've chosen not to, they likely will just explain that when the reporter makes initial contact, and thus fail to meet the 4th item in the description. + - We've observed that some novice vendors react quite negatively to reporters who accompany their initial contact with what may appear to be a demand for payment. That's not to say that the finder or reporter intended their "do you have a bug bounty?" inquiry as an attempted extortion of course. + - Our recommendation to finders and reporters is that if payment for their services is expected, they do their best to find out whether the vendor offers a bounty program (and its scope) prior to embarking on any significant effort to find vulnerabilities. It's unlikely that a reporter will be able to cajole a vendor without an existing bounty to create one during the course of a single CVD case. diff --git a/docs/howto/recipes/_x05.md b/docs/howto/recipes/_x05.md new file mode 100644 index 0000000..c316858 --- /dev/null +++ b/docs/howto/recipes/_x05.md @@ -0,0 +1,20 @@ + +!!! warning "Vendor has a reputation for or history of treating reporters poorly" + + !!! warning inline end "" + + **Role(s) affected:** Reporter + + **Phase(s):** Reporting + + **Description:** + + 1. The reporter wishes to report a vulnerability to the vendor + 2. The vendor has a history of treating reporters poorly (retaliation, threatened litigation, etc.) + + - Assuming the reporter chooses to continue pursuing the issue at all, their options include: + - The Reporter may publish the report on their own, possibly anonymously. + - The Reporter may attempt to engage a Coordinator to act as a neutral third party + - The Reporter may attempt to engage a Coordinator to act as an anonymizing proxy to relay the information to the Vendor + - The Reporter may take steps to report the vulnerability to the Vendor anonymously. + - The CERT/CC recommends that Reporters do their best to provide Vendors with an opportunity to resolve vulnerabilities prior to public disclosure. However if the Vendor's prior behavior makes that infeasible it's our opinion that there is a benefit to public awareness of the vulnerability regardless. diff --git a/docs/howto/recipes/_x06.md b/docs/howto/recipes/_x06.md new file mode 100644 index 0000000..a64d697 --- /dev/null +++ b/docs/howto/recipes/_x06.md @@ -0,0 +1,24 @@ + +!!! warning "Vendor stops responding" + + !!! warning inline end "" + + **Role(s) affected:** Reporter + + **Phase(s):** Reporting, Validation and prioritization, Remediation, Public Awareness + + **Description:** + + 1. The reporter and vendor had already been in contact about the vulnerability. + 2. The reporter has repeatedly attempted to communicate with the vendor. + 3. The vendor has been non-responsive for at least two weeks + 4. Either of the following events has occurred: + 1. An already-agreed embargo date has passed, or + 2. No embargo date was set and at least six weeks have elapsed since the vendor's last response. + + - At this point, the CERT/CC would consider the vendor to be non-responsive. + - Assuming the reporter chooses to continue pursuing the issue at all, their options include: + - The reporter may publish the report on their own. + - If so, the reporter should provide a courtesy copy of the report to the vendor with a few days' lead time to give the vendor one last chance to prepare for entering the Public Awareness phase. + - The reporter may attempt to engage a coordinator + - See [Somebody Stops Replying](../coordination/somebody_stops_replying.md) diff --git a/docs/howto/recipes/_x07.md b/docs/howto/recipes/_x07.md new file mode 100644 index 0000000..ae9c92f --- /dev/null +++ b/docs/howto/recipes/_x07.md @@ -0,0 +1,23 @@ + +!!! warning "Vendor explicitly declines to take action on a report" + + !!! warning inline end "" + + **Role(s) affected:** Reporter + + **Phase(s):** Validation and prioritization + + **Description:** + + 1. The vendor has been given an opportunity to review the report + 2. The vendor informs the reporter of its decision not to take any further action + + - Assuming + - both conditions in the description have been met, + - the validation and prioritization phase has concluded, and + - the vendor has indicated that they will not be engaging in the remediation phase. + - The reporter's implied obligation to the vendor coordination process is effectively terminated at this point. + - If the reporter chooses to continue pursuing the issue at all, their options include: + - The reporter may publish the report on their own. + - The reporter may attempt to engage a coordinator + - See [Unresponsive Vendor](../initiation/unresponsive_vendor.md) and [Somebody Stops Replying](../coordination/somebody_stops_replying.md). diff --git a/docs/howto/recipes/_x08.md b/docs/howto/recipes/_x08.md new file mode 100644 index 0000000..d3f64b1 --- /dev/null +++ b/docs/howto/recipes/_x08.md @@ -0,0 +1,20 @@ + +!!! warning "Vendor is unprepared for pending embargo expiration" + + !!! warning inline end "" + + **Role(s) affected:** Reporter, Coordinator + + **Phase(s):** Remediation + + **Description:** + + 1. The Vendor is aware of the vulnerability. + 2. The embargo date is approaching. + 3. The Vendor communicates that it is not ready yet. + + - Reporters and Coordinators should consider the Vendor's responsiveness to date when deciding how to respond. + - If the Vendor is cooperative and seems to have a reasonable explanation for the delay, extending the embargo may be preferable. + - If the Vendor has had ample time to address the problem and does not appear to be acting in good faith toward a timely resolution, Reporters may choose to publish the vulnerability information on their own without the Vendor's participation. Alternatively, Reporters may choose to engage the services of a Coordinator to try to resolve the conflict. + - In no case is it necessary for the Reporter or Coordinators to wait indefinitely for a Vendor that does not appear to be making progress toward timely resolution. + - See [Disclosure Timing](../coordination/disclosure_timing.md) for more information on this topic. diff --git a/docs/howto/recipes/_x09.md b/docs/howto/recipes/_x09.md new file mode 100644 index 0000000..11fb986 --- /dev/null +++ b/docs/howto/recipes/_x09.md @@ -0,0 +1,17 @@ + +!!! warning "A CVD case involves too many vendors or is otherwise excessively complex." + + !!! warning inline end "" + + **Role(s) affected:** Reporter, Vendor + + **Phase(s):** Reporting, Validation and prioritization, Remediation, Public Awareness + + **Description:** + + 1. Multiple vendors are likely to be affected by the vulnerability. + 2. The reporter or Vendor(s) already involved are concerned about their ability to notify and coordinate other Vendors' response to the vulnerability. + + - Reporters and Vendors can engage the services of a third party Coordinator to assist with notifying other Vendors, coordinating response along a supply chain, resolving disputes, etc. + - Reporters and Vendors should consider shortening the embargo period for larger multiparty cases. The chance of embargo failure grows dramatically as more parties are added to the coordination. + - See [Multiparty CVD](../coordination/mpcvd.md), [Response Pacing and Synchronization](../coordination/response_pacing.md), and [Maintaining Pre-Disclosure Secrecy](../coordination/maintaining_secrecy.md) diff --git a/docs/howto/recipes/_x10.md b/docs/howto/recipes/_x10.md new file mode 100644 index 0000000..8055733 --- /dev/null +++ b/docs/howto/recipes/_x10.md @@ -0,0 +1,19 @@ + +!!! warning "Reporter stops responding" + + !!! warning inline end "" + + **Role(s) affected:** Vendor + + **Phase(s):** Reporting, Validation and prioritization, Remediation, Public Awareness + + **Description:** + + 1. The reporter and vendor had already been in contact about the vulnerability. + 2. The vendor has repeatedly attempted to communicate with the reporter. + 3. The reporter has not responded to the vendor. + + - The vendor is under no obligation to continue attempting to engage with a reporter who stops responding. + - The vendor should continue through the Validation and prioritization, Remediation, and Public Awareness phases on their own as necessary. + - If the report was received in the context of a bug bounty program, the vendor should apply their bug bounty policy as appropriate. + - See [Somebody Stops Replying](../coordination/somebody_stops_replying.md). diff --git a/docs/howto/recipes/_x11.md b/docs/howto/recipes/_x11.md new file mode 100644 index 0000000..6d89c79 --- /dev/null +++ b/docs/howto/recipes/_x11.md @@ -0,0 +1,21 @@ + +!!! warning "Vulnerability becomes public prior to vendor intended date" + + !!! warning inline end "" + + **Role(s) affected:** Vendor + + **Phase(s):** Reporting, Validation and prioritization, Remediation + + **Description:** + + 1. The vendor had received the report. + 2. The vendor is working on it. + 3. Information about the vulnerability appears in public. + + - At this point, the embargo is effectively moot, and the Public Awareness phase is initiated regardless of whether the preceding phases have completed. + - Vendors, Coordinators, and Reporters should always be ready to immediately terminate an embargo and go public with whatever advice is available at the time that the vulnerability becomes known. + - The Vendor should accelerate their remediation development as much as possible. + - Even a simple Vendor acknowledgement that the problem is being worked on can help deployers adjust their response accordingly. + - The CERT/CC does not recommend punitive measures be taken against perceived "leakers". Vendors are of course free to choose with whom they cooperate in the future. + - See [Disclosure Timing](../coordination/disclosure_timing.md), [Leaks](../coordination/leaks.md), and [Independent Discovery](../coordination/independent_discovery.md) diff --git a/docs/howto/recipes/_x12.md b/docs/howto/recipes/_x12.md new file mode 100644 index 0000000..e89195d --- /dev/null +++ b/docs/howto/recipes/_x12.md @@ -0,0 +1,18 @@ + +!!! warning "Vulnerability becomes public prior to vendor awareness of the vulnerability" + + !!! warning inline end "" + + **Role(s) affected:** Vendor + + **Phase(s):** Reporting + + **Description:** + + 1. The vendor was unaware of the vulnerability at the time it became public. + + - The main defenses Vendors have against being surprised by public reports of vulnerabilities in their products are: + - Vendors should have a mechanism for receiving vulnerability reports and a process for resolving them + - Vendors should strive to maintain a reputation for cooperating with Finders and Reporters + - Vendors should design, evaluate, and test their own products as extensively as they are able to. + - See [Disclosure Timing](../coordination/disclosure_timing.md), [Intentional or Accidental Leaks](../coordination/leaks.md), and [Independent Discovery](../coordination/independent_discovery.md) for more information on this topic. diff --git a/docs/howto/recipes/_x13.md b/docs/howto/recipes/_x13.md new file mode 100644 index 0000000..4640d01 --- /dev/null +++ b/docs/howto/recipes/_x13.md @@ -0,0 +1,21 @@ + +!!! warning "Vendor receives report outside the scope of their reporting program" + + !!! warning inline end "" + + **Role(s) affected:** Vendor + + **Phase(s):** Reporting, Validation and prioritization + + **Description:** + + 1. The vendor operates a vulnerability disclosure program with a defined scope. + 2. A report is received that falls outside of that scope. + + - Reports received in CVD programs don't always fall neatly within the vendor's predefined scope for their vulnerability disclosure policy. In most cases, that shouldn't matter, because: + - If the report is for a vulnerability that the vendor is able to fix, the vendor should proceed with the rest of the CVD process as if it were in scope + - If the report is for a vulnerability that the vendor is unable to fix (e.g., it's not in the vendor's product but in a library) the vendor may redirect the reporter to the originating vendor, or could act as a coordinator and engage the upstream vendor directly. + - If the report is not for a vulnerability but represents a security incident (e.g., data leaked on an open server), the vendor can handle it as a security incident. + - If the report is for a bug that is otherwise not a vulnerability, the vendor can route the report to the appropriate developers for remediation. + - In each of these cases, the reporter has provided useful information that is actionable by the vendor. Misdirected (out of scope) reports provide vendors an opportunity to review and revise their published documentation and policies to ensure they're communicating clearly what they do and do not expect to receive via their CVD program. + - Even if the report indicates that the finder or reporter went far beyond the vendor's policy, it may still be appropriate to handle the report as if it were in compliance in order to avoid causing further problems for either the vendor or the reporter. Reporters can often be redirected toward acceptable future behavior if their initial oversteps are treated as teachable moments rather than violations in need of punishment. diff --git a/docs/howto/recipes/_x14.md b/docs/howto/recipes/_x14.md new file mode 100644 index 0000000..a1e3d94 --- /dev/null +++ b/docs/howto/recipes/_x14.md @@ -0,0 +1,21 @@ + +!!! warning "Vendor suspects the finder violated its policy in the process of finding a vulnerability." + + !!! warning inline end "" + + **Role(s) affected:** Vendor + + **Phase(s):** Reporting, Validation and prioritization, Remediation + + **Description:** + + 1. Vendor received report. + 2. Vendor's analysis indicates that other policies were violated in the discovery process. + + - There are two issues at hand in this case: + 1. Is there a vulnerability that the vendor needs to respond to? + 2. Do the finder's actions constitute a security incident? + - Answering the first question in the affirmative, the vendor should proceed as normal through the remediation and public awareness phases. + - If the finder's actions are determined to qualify as a security incident of their own, the vendor would do well to consider the implied beneficence on the part of the reporter in providing the report to the vendor in the first place. Yes, rules may have been broken, but sometimes an _All's Well that Ends Well_ response is preferable. + - Gently reminding the reporter of the vendor's expectations can help solidify a positive relationship between the vendor and the research community. + - That said, the above advice should not be construed as a recommendation that vendors acquiesce to aggression or abuse from finders or reporters. diff --git a/docs/howto/recipes/_x15.md b/docs/howto/recipes/_x15.md new file mode 100644 index 0000000..05d4c23 --- /dev/null +++ b/docs/howto/recipes/_x15.md @@ -0,0 +1,19 @@ + +!!! warning "Vendor receives second report of a vulnerability already under embargo" + + !!! warning inline end "" + + **Role(s) affected:** Vendor + + **Phase(s):** Reporting, Validation and prioritization,Remediation + + **Description:** + + 1. The vendor had received a report of a vulnerability + 2. The vendor received a second, seemingly independent, report of the same vulnerability + + - Vulnerability rediscovery is known to happen. It's usually not a big deal if the Reporters are cooperating with the Vendor. + - Vendors should attempt to verify that the second report is in fact independent of the first, and not simply a case of the same report taking diverse paths to reach the vendor. + - Vendors should re-evaluate any existing embargo and consider accelerating the Remediation and Public Awareness phases in light of the apparent ease with which the vulnerability is being independently found. + - Vendors should ensure any relevant bug bounty policies define how this situation will be handled with respect to bounty payouts. + - If the second report is made in public rather than directly to the vendor, see also _Vulnerability becomes public prior to vendor intended date_. diff --git a/docs/howto/recipes/_x16.md b/docs/howto/recipes/_x16.md new file mode 100644 index 0000000..68c39eb --- /dev/null +++ b/docs/howto/recipes/_x16.md @@ -0,0 +1,22 @@ + +!!! warning "Vulnerability affects downstream vendors" + + !!! warning inline end "" + + **Role(s) affected:** Vendor + + **Phase(s):** Validation and prioritization, Remediation + + **Description:** + + 1. Multiple vendors are likely to be affected by the vulnerability. + 2. Many of these vendors are dependent on the originating vendor providing a fix before they can take action. + 3. The originating vendor may or may not know exactly who those downstream vendors are or how to reach them. + + - Questions of fairness arise if some affected vendors are given advance notice of a vulnerability while others are notified only when it reaches the Public Awareness phase. The goal should be to provide as much information as soon as possible to all affected vendors. + - Vendors should provide communication channels for their downstream vendors to coordinate vulnerability response when needed. Ideally these channels are established and maintained on an ongoing basis, because constructing them in an ad-hoc manner in the midst of a vulnerability case can be time consuming and error prone. + - Vendors may wish to provide an extended embargo period so that their downstream vendors have an opportunity to incorporate changes before entering the Public Awareness phase. This obviously works better in cases where the originating vendor knows who most of its downstream vendors are. (See Vulnerability affects unknown downstream vendors for additional advice when they don't.) + - Cases where a significant user base (in terms of size or relative importance) may be affected by the vulnerability via unknown downstream vendors' products are an argument in favor of shortened embargo periods and increased Public Awareness. + - Furthermore, the larger the number of involved parties, the more likely the embargo is to fail. Vendors in a supply chain may consider whether legally binding disclosure agreements are an appropriate means to limit this risk. However, it's often not feasible for all parties to be placed under such an agreement, which again argues in favor of short embargo periods. + - Reporters and Vendors can engage the services of a third party Coordinator to assist with notifying other Vendors, coordinating response along a supply chain, resolving disputes, etc. + - See [Multiparty CVD](../coordination/mpcvd.md), [Response Pacing and Synchronization](../coordination/response_pacing.md), and [Maintaining Pre-Disclosure Secrecy](../coordination/maintaining_secrecy.md) diff --git a/docs/howto/recipes/_x17.md b/docs/howto/recipes/_x17.md new file mode 100644 index 0000000..71514e4 --- /dev/null +++ b/docs/howto/recipes/_x17.md @@ -0,0 +1,20 @@ + +!!! warning "Vulnerability affects unknown downstream vendors" + + !!! warning inline end "" + + **Role(s) affected:** Reporter, Vendor, Coordinator + + **Phase(s):** Validation and prioritization, Remediation + + **Description:** + + 1. Multiple vendors are likely to be affected by the vulnerability. + 2. Many of these vendors are dependent on the originating vendor providing a fix before they can take action. + 3. The originating vendor does not know exactly who those downstream vendors are or how to reach them. + + - Questions of fairness arise if some affected vendors are given advance notice of a vulnerability while others are notified only when it reaches the Public Awareness phase. The goal should be to provide as much information as soon as possible to all affected vendors. + - Vendors should provide communication channels for their downstream vendors to coordinate vulnerability response when needed. Ideally these channels are established and maintained on an ongoing basis, because constructing them in an ad-hoc manner in the midst of a vulnerability case can be time consuming and error prone. + - For vulnerabilities affecting a large number of unknown downstream vendors, the Public Awareness phase plays an important part in identifying those vendors. Although publication may catch those by surprise in this case, it should also help establish the aforementioned contact channel for future cases. + - Reporters and Vendors can engage the services of a third party Coordinator to assist with notifying other Vendors, coordinating response along a supply chain, resolving disputes, etc. + - See [Multiparty CVD](../coordination/mpcvd.md), [Response Pacing and Synchronization](../coordination/response_pacing.md), and [Maintaining Pre-Disclosure Secrecy](../coordination/maintaining_secrecy.md) diff --git a/docs/howto/recipes/_x18.md b/docs/howto/recipes/_x18.md new file mode 100644 index 0000000..4fbff88 --- /dev/null +++ b/docs/howto/recipes/_x18.md @@ -0,0 +1,21 @@ + +!!! warning "Vulnerability affects multiple vendors with incompatible disclosure policies" + + !!! warning inline end "" + + **Role(s) affected:** Reporter, Vendor, Coordinator + + **Phase(s):** Reporting, Validation and prioritization, Remediation + + **Description:** + + 1. Multiple vendors are likely to be affected by the vulnerability. + 2. At least one of those vendors has a policy or practice of disclosing vulnerabilities more quickly than others. + 3. That vendor is unwilling to adjust their behavior to accommodate slower vendors. + + - The coordinating parties (Reporter, Vendor(s), and/or Coordinator) have three options: + 1. Shorten their embargo to accommodate the fast-moving vendor + 2. Delay notifying the the fast-moving vendor until the other vendors are close enough that they'll be ready for the Public Awareness phase at the same time as the fast-moving vendor + 3. Avoid notifying the fast-moving vendor during the embargo period, letting them catch up once the vulnerability enters the Public Awareness phase. + - The third is nearly always the least optimal of the three choices. + - See [Multiparty CVD](../coordination/mpcvd.md), [Response Pacing and Synchronization](../coordination/response_pacing.md), and [Maintaining Pre-Disclosure Secrecy](../coordination/maintaining_secrecy.md) diff --git a/docs/howto/recipes/_x19.md b/docs/howto/recipes/_x19.md new file mode 100644 index 0000000..72432ac --- /dev/null +++ b/docs/howto/recipes/_x19.md @@ -0,0 +1,18 @@ + +!!! warning "Vendor is unprepared for pending embargo expiration" + + !!! warning inline end "" + + **Role(s) affected:** Vendor + + **Phase(s):** Remediation + + **Description:** + + 1. The Vendor is aware of the vulnerability. + 2. The embargo date is approaching. + 3. The Vendor is not ready yet. + + - If the Vendor is working toward a solution but needs more time to complete its analysis, development, or testing, it can request an extension of the embargo from the Reporter and/or Coordinator (if any). + - Vendors should recognize that (absent any binding agreement to the contrary) the embargo is a courtesy offered by the Reporter or Coordinator to the Vendor, but that Reporter or Coordinator policy or other considerations may supersede the Vendor's desire for more time. + - See [Disclosure Timing](../coordination/disclosure_timing.md) diff --git a/docs/howto/recipes/_x20.md b/docs/howto/recipes/_x20.md new file mode 100644 index 0000000..0357e5f --- /dev/null +++ b/docs/howto/recipes/_x20.md @@ -0,0 +1,22 @@ + +!!! warning "A vulnerability is receiving unanticipated media attention" + + !!! warning inline end "" + + **Role(s) affected:** Vendor + + **Phase(s):** Public Awareness + + **Description:** + + 1. The vendor is aware of the vulnerability, and may have already released a fix. + 2. There is considerable media attention drawn to the vulnerability. + 3. Sometimes this is triggered by savvy marketing on the part of the Finder or Reporter + 4. Other times this attention comes about because of recent similar media stories. + 5. Often the media attention is disproportionate to the severity of the vulnerability. + + - Sometimes this is triggered by savvy marketing on the part of the Finder or Reporter + - Other times this attention comes about because of recent similar media stories. + - Often the media attention is disproportionate to the severity of the vulnerability. + - Vendors and Coordinators (if any are involved) can often help their users, constituents, and the media to appropriately calibrate their concern about a vulnerability by providing a clear and accurate representation of the facts. + - Vendors should not attempt to squash the information already available in the public sphere however. This often backfires, leading to even more publicity. It's better to let the vulnerability be the story rather than have the Vendor's response to the vulnerability become the story. diff --git a/docs/howto/recipes/_x21.md b/docs/howto/recipes/_x21.md new file mode 100644 index 0000000..30ecac3 --- /dev/null +++ b/docs/howto/recipes/_x21.md @@ -0,0 +1,16 @@ + +!!! warning "A CVD case just isn't going well" + + !!! warning inline end "" + + **Role(s) affected:** Reporter, Vendor, Coordinator + + **Phase(s):** Reporting, Validation and prioritization, Remediation, Public Awareness + + **Description:** + + 1. Cooperation has failed or is in the process of failing within the context of a particular CVD case. + + - All parties in a failing CVD case should consider their actions in light of promoting continued cooperation. + - Reporters and Vendors can [engage the services of a third party Coordinator](../coordination/coordinator_reasons.md) to assist with notifying other Vendors, coordinating response along a supply chain, resolving disputes, etc. + - See [Relationships that Go Sideways](../coordination/relationships_sideways.md) diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 0000000..0d457bc --- /dev/null +++ b/docs/index.md @@ -0,0 +1,44 @@ +# The CERT Guide to Coordinated Vulnerability Disclosure + +!!! tip inline end "Original Report" + + The CERT Guide to Coordinated Vulnerability Disclosure was originally published as + [CMU/SEI-2017-SR-022](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=503330) + + This web version is an evolution of that original report. + +This is the web edition of *The CERT® Guide to Coordinated Vulnerability +Disclosure*. We started with the original report in its entirety and +have been working to make it more accessible and easier to navigate. +We're also in the process of revising the guide based on feedback we've received +since its original publication. + +Got a suggestion? [Submit it here](https://github.com/CERTCC/CERT-Guide-to-CVD/issues). + + +
+
+ +!!! abstract "What is *The CERT Guide to CVD* about?" + + Security vulnerabilities remain a problem for vendors and deployers of + software-based systems alike. Vendors play a key role by providing fixes + for vulnerabilities, but they have no monopoly on the ability to + discover vulnerabilities in their products and services. Knowledge of + those vulnerabilities can increase adversarial advantage if deployers + are left without recourse to remediate the risks they pose. Coordinated + Vulnerability Disclosure (CVD) is the process of gathering information + from vulnerability finders, coordinating the sharing of that information + between relevant stakeholders, and disclosing the existence of software + vulnerabilities and their mitigations to various stakeholders including + the public. The CERT Coordination Center has been coordinating the + disclosure of software vulnerabilities since its inception in 1988. This + documentation is intended to serve as a guide to those who want to initiate, + develop, or improve their own CVD capability. In it, the reader will + find an overview of key principles underlying the CVD process, a survey + of CVD stakeholders and their roles, and a description of CVD process + phases, as well as advice concerning operational considerations and + problems that may arise in the provision of CVD and related services. + +{% include-markdown "./_includes/_quick_start.md" heading-offset=1 %} +{% include-markdown "./_includes/_community_engagement.md" heading-offset=1 %} diff --git a/docs/javascripts/mathjax.js b/docs/javascripts/mathjax.js new file mode 100644 index 0000000..06dbf38 --- /dev/null +++ b/docs/javascripts/mathjax.js @@ -0,0 +1,16 @@ +window.MathJax = { + tex: { + inlineMath: [["\\(", "\\)"]], + displayMath: [["\\[", "\\]"]], + processEscapes: true, + processEnvironments: true + }, + options: { + ignoreHtmlClass: ".*|", + processHtmlClass: "arithmatex" + } +}; + +document$.subscribe(() => { + MathJax.typesetPromise() +}) diff --git a/docs/javascripts/tablesort.js b/docs/javascripts/tablesort.js new file mode 100644 index 0000000..6a5afcf --- /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/docs/reference/certcc_disclosure_policy.md b/docs/reference/certcc_disclosure_policy.md new file mode 100644 index 0000000..a97c864 --- /dev/null +++ b/docs/reference/certcc_disclosure_policy.md @@ -0,0 +1,96 @@ +# Vulnerability Disclosure Policy + +Vulnerabilities reported to the CERT/CC will be disclosed to the public 45 days +after the initial report, regardless of the existence or availability of +patches or workarounds from affected vendors. Extenuating circumstances, +such as active exploitation, threats of an especially serious (or +trivial) nature, or situations that require changes to an established +standard may result in earlier or later disclosure. Disclosures made by +the CERT/CC will include credit to the reporter unless otherwise +requested by the reporter. We will apprise any affected vendors of our +publication plans and negotiate alternate publication schedules with the +affected vendors when required. + +It is the goal of this policy to balance the need of the public to be +informed of security vulnerabilities with vendors' need for time to +respond effectively. The final determination of a publication schedule +will be based on the best interests of the community overall. + +Vulnerabilities reported to us will be forwarded to the affected vendors +as soon as practical after we receive the report. The name and contact +information of the reporter will be forwarded to the affected vendors +unless otherwise requested by the reporter. We will advise the reporter +of significant changes in the status of any vulnerability he or she +reported to the extent possible without revealing information provided +to us in confidence. + +Vulnerabilities will be disclosed in [Vulnerability Notes](http://www.kb.cert.org/vuls). + +Vulnerability reports for U.S. Government web sites will be forwarded +to [CISA](http://www.cisa.gov/) for coordination with the government. + +## Frequently Asked Questions + +
+ +!!! question "Why not 30 days, or 15 days, or immediately?" + + We think that 45 days can be a pretty tough deadline for a large + organization to meet. Making it shorter won't realistically help the + problem. In the absence of evidence of exploitation, gratuitously + announcing vulnerabilities may not be in the best interest of public + safety. + +!!! question "Wouldn't it be better to keep vulnerabilities quiet if there isn't a fix available?" + + Vulnerabilities are routinely discovered and disclosed, + frequently before vendors have had a fair opportunity to provide a fix, + and disclosure often includes working exploits. In our experience, if + there is not responsible, qualified disclosure of vulnerability + information then researchers, programmers, system administrators, and + other IT professionals who discover vulnerabilities often feel they have + no choice but to make the information public in an attempt to coerce + vendors into addressing the problem. + +!!! question "Will all vulnerabilities be disclosed within 45 days?" + + No. There may often be circumstances that will cause us to adjust + our publication schedule. Threats that are especially serious or for + which we have evidence of exploitation will likely cause us to shorten + our release schedule. Threats that require _hard_ changes (changes to + standards, changes to core operating system components) will cause us to + extend our publication schedule. We may not publish every vulnerability + that is reported to us. + +!!! question "Will you surprise vendors with announcements of vulnerabilities?" + + No. Prior to public disclosure, we'll make a good faith effort + to inform vendors of our intentions. + +!!! question "If a vendor disagrees with your assessment of a problem, will that information be available?" + + Yes. We solicit and post authenticated vendor statements and + reference relevant vendor information in vulnerability notes. We will + not withhold vendor-supplied information simply because it disagrees + with our assessment of the problem. + +!!! question "Who gets the information prior to public disclosure?" + + Generally, we provide the information to anyone who can + contribute to the solution and with whom we have a trusted relationship, + including vendors (often including vendors whose products are not + vulnerable), community experts, sponsors, and sites that are part of a + national critical infrastructure, if we believe those sites to be at + risk. + +!!! question "Do you disclose every reported vulnerability?" + + No. We may, at our discretion, decline to coordinate or publish a + vulnerability report. This decision is generally based on the scope and + severity of the vulnerability and our ability to add value to the + coordination and disclosure process. Whether or not we coordinate or + publish, we recommend that the reporter make a good faith effort to + notify and work directly with the affected vendor prior to public + disclosure. + +
diff --git a/docs/reference/disclosure_policy_templates.md b/docs/reference/disclosure_policy_templates.md new file mode 100644 index 0000000..7211597 --- /dev/null +++ b/docs/reference/disclosure_policy_templates.md @@ -0,0 +1,33 @@ +# Disclosure Policy Resources + + + +Following are some resources that can help you create a disclosure policy: + +- CISA provides a [Vulnerability Disclosure Policy Template](https://www.cisa.gov/vulnerability-disclosure-policy-template) + for U.S. Federal Agencies. This template is also useful as a starting point for other organizations + looking to establish a vulnerability disclosure policy. + +- UK National Cyber Security Centre has a [policy template](https://github.com/ukncsc/Vulnerability-Disclosure) as part of their + [Vulnerability Disclosure Toolkit](https://www.ncsc.gov.uk/information/vulnerability-disclosure-toolkit) + +- The [disclose.io](https://disclose.io/) [Policymaker](https://policymaker.disclose.io/policymaker/introduction) tool can help you create a policy that fits your organization's needs. + +- CERT/CC has a set of [Disclosure Policy Templates](https://github.com/CERTCC/vulnerability_disclosure_policy_templates) + derived from multiple sources. Our templates are a collection of statements that can be used to create a policy that fits your organization's needs. + +- [IETF RFC 2350](https://datatracker.ietf.org/doc/html/rfc2350) provides recommendations on how to publish information about your CSIRT and disclosure policy and procedures. + +- [ISO/IEC 29147:2018 *Information technology -- Security techniques -- Vulnerability disclosure*](https://www.iso.org/standard/72311.html) provides guidelines for vulnerability disclosure, including a section on required, recommended, and optional policy elements. + +- NTIA ["Early Stage" Coordinated Vulnerability Disclosure Template Version 1.1](https://www.ntia.doc.gov/files/ntia/publications/ntia_vuln_disclosure_early_stage_template.pdf) has suggested templates for safety-critical sectors. + +- [security.txt](https://securitytxt.org/) is a proposed standard which allows websites to define security policies. + +- [ENISA Good Practice Guide on Vulnerability Disclosure](https://www.enisa.europa.eu/publications/vulnerability-disclosure) includes an annotated vulnerability disclosure policy template as an Annex. + +- The United States Department of Justice (DoJ) has published a + [Framework for a Vulnerability Disclosure Program for Online Systems](https://www.justice.gov/criminal-ccips/page/file/983996/download) + containing guidance aimed at developing vulnerability disclosure programs for online systems and services. + + diff --git a/docs/reference/index.md b/docs/reference/index.md new file mode 100644 index 0000000..6ad56d2 --- /dev/null +++ b/docs/reference/index.md @@ -0,0 +1,14 @@ +# CVD Reference Information + +We have assembled a few resources to help you dig deeper into Coordinated Vulnerability Disclosure (CVD) and related topics. +These resources include templates, standards, and other materials that can help you understand and implement CVD in your organization. + +
+ +- :octicons-checklist-16: [CERT/CC Vulnerability Disclosure Policy](./certcc_disclosure_policy.md) +- :material-form-select: [Basic Vulnerability Reporting Form](./simple_vrf.md) +- :material-newspaper-variant: [Basic Advisory Format](./simple_advisory.md) +- :material-clipboard-check-multiple-outline: [Disclosure Policy Resources](./disclosure_policy_templates.md) +- :material-bookshelf: [CVD Resources and Standards](./resources.md) + +
diff --git a/docs/reference/resources.md b/docs/reference/resources.md new file mode 100644 index 0000000..497e578 --- /dev/null +++ b/docs/reference/resources.md @@ -0,0 +1,45 @@ +# Resources and Standards + +Here we have collected a list of resources and standards that are relevant to the practice and process of +Coordinated Vulnerability Disclosure (CVD). +This list is by no means exhaustive, but it should provide a good starting point for those interested in learning more about CVD. + +## ISO Standards + +- [ISO/IEC 30111:2019](https://www.iso.org/standard/69725.html) Information technology -- Security techniques -- Vulnerability handling processes +- [ISO/IEC 29147:2018](https://www.iso.org/standard/72311.html) Information technology -- Security techniques -- Vulnerability disclosure +- [ISO/IEC TR 5895:2022](https://www.iso.org/standard/81807.html) Cybersecurity Multi-party coordinated vulnerability disclosure and handling + +## FIRST Resources + +- [Traffic Light Protocol (TLP)](https://www.first.org/tlp/) +- [Common Vulnerability Scoring System (CVSS)](https://www.first.org/cvss/) +- [Vulnerability Coordination Special Interest Group](https://www.first.org/global/sigs/vulnerability-coordination/) +- [Ethics Special Interest Group](https://www.first.org/global/sigs/ethics/) +- [PSIRT Services Framework](https://www.first.org/standards/frameworks/psirts/psirt_services_framework_v1.1) +- [CSIRT Services Framework](https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1) + +## OASIS Resources + +- [Common Security Advisory Framework (CSAF)](https://oasis-open.github.io/csaf-documentation/) + +## NIST Resources + +- [National Vulnerability Database (NVD)](https://nvd.nist.gov/) +- [Common Platform Enumeration (CPE)](https://nvd.nist.gov/products/cpe) +- [NIST SP 800-161 Rev. 1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/161/r1/final) + +## CERT Resources + +- [Stakeholder-Specific Vulnerability Categorization (SSVC)](https://certcc.github.io/SSVC/): A framework for prioritizing vulnerabilities based on stakeholder needs +- [Vultron](https://certcc.github.io/Vultron/): A protocol for Multi-Party Vulnerability Coordination +- [CERT Resilience Management Model (CERT-RMM)](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=508099) +- [Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE)](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=508099) +- [Vulnerability Disclosure Policy Templates](https://github.com/CERTCC/vulnerability_disclosure_policy_templates) +- [Vulnerability INformation and Coordination Environment](https://github.com/CERTCC/VINCE) (VINCE) + +## CISA Resources + +- [Software Bill of Materials (SBOM)](https://www.cisa.gov/SBOM) +- [Vulnerability Disclosure Policy (VDP) Platform](https://www.cisa.gov/resources-tools/services/vulnerability-disclosure-policy-vdp-platform) +- [Vulnerability Disclosure Policy Template](https://www.cisa.gov/vulnerability-disclosure-policy-template) diff --git a/docs/reference/simple_advisory.md b/docs/reference/simple_advisory.md new file mode 100644 index 0000000..e420aaa --- /dev/null +++ b/docs/reference/simple_advisory.md @@ -0,0 +1,96 @@ +# Basic Vulnerability Advisory Document + +The vulnerability disclosure document is also often referred to as a +"security advisory," particularly if published by the vendor. + +This is an example of a vulnerability disclosure document based on +CERT/CC's [Vulnerability Notes](https://www.kb.cert.org/vuls/) format. +It is not meant to be exhaustive of all scenarios. + +Please modify the sections and format as necessary to better suit your +needs. + +!!! tip "Common Security Advisory Format" + + The [Common Security Advisory Format](https://oasis-open.github.io/csaf-documentation/) (CSAF) is a standardized + format for publishing security advisories. It is designed to be machine-readable and is + intended to be used by vendors, coordinators, and reporters to communicate with the public about vulnerabilities. + +## Vulnerability Disclosure Document + +### Overview + +- Brief Vulnerability Description: (try to keep it to 1-2 sentences) + +### Vulnerability ID + +- CVE ID for this Vulnerability: + +- Any other IDs (vendor tracking ID, bug tracker ID, CERT ID, etc.): + +### Description + +- Software/Product(s) containing the vulnerability: + +- Version number of vulnerable software/product: + +- Product Vendor: + +- Type of Vulnerability, if known: (see [MITRE's + CWE](https://cwe.mitre.org/) site for + list of common types of vulnerabilities) + +- Vulnerability Description: + +- How may an attacker exploit this vulnerability? (Proof of Concept): + +### Impact + +- What is the impact of exploiting this vulnerability? (What does an + attacker gain that the attacker didn't have before?) + +### CVSS Score + +- CVSS:3.0/AV:?/AC:?/PR:?/UI:?/S:?/C:?/I:?/A:? -- 0.0 + (LOW/MEDIUM/HIGH/CRITICAL) + +- Provide the full CVSS vector, not only the score. If possible, + provide guidance on the temporal and environmental metrics, not only + the base metrics. See + [https://www.first.org/cvss/](https://www.first.org/cvss/) + +### Resolution + +- Version containing the fix: +- URL or contact information to obtain the fix: +- Alternately, if no fix is available, list workaround or mitigation + advice below: + +### Reporter + +This vulnerability was reported/discovered by +\_\_\_\_\_\_\_\_\_\_\_\_\_. + +### Author and/or Contact Info + +For more information or questions, please contact: + +- Name: +- Organization: +- Email: +- PGP Public Key (ASCII Armored or a URL): + +### Disclosure Timeline + +- Date of First Vendor Contact Attempt: +- Date of Vendor Response: +- Date of Patch Release: +- Disclosure Date: + +(List more dates here as necessary to document your communication +attempts.) + +### References + +(List reference URLs here: for example, vendor advisory, other +disclosures, and links to advice on mitigating problems.) diff --git a/docs/reference/simple_vrf.md b/docs/reference/simple_vrf.md new file mode 100644 index 0000000..28b3501 --- /dev/null +++ b/docs/reference/simple_vrf.md @@ -0,0 +1,56 @@ +# Basic Vulnerability Report Form + +Organizations that need to receive vulnerability reports should have a form that helps them collect the necessary +information. +This form should be easy to use and understand, and should help the reporter provide the information needed to +understand and address the vulnerability. +Specific details may vary depending on the organization's needs and its role(s) in the CVD process +([Vendor](../topics/roles/vendor.md), [Coordinator](../topics/roles/coordinator.md), etc.), but +much of the content will be the same across organizations. + +This page contains a report example based on the CERT/CC's [Vulnerability +Reporting Form](https://www.kb.cert.org/vuls/report/), and is not meant to be exhaustive of all possibilities. +Please modify the sections and format as necessary to better suit your +needs. + +## Vulnerability Report + +!!! question "Tell us about the Vulnerability" + + - Software/Product(s) containing the vulnerability + - Vulnerability Description + - How may an attacker exploit this vulnerability? (Proof of Concept) + - What is the impact of exploiting this vulnerability? (What does an attacker gain that the attacker didn't have before?) + - How did you find the vulnerability? (Be specific about tools and versions you used.) + - When did you find the vulnerability? + +!!! question "What are your disclosure plans?" + + - Have you already reported this vulnerability to the following vendors and organizations? YES | NO + - Is this vulnerability being publicly discussed? YES | NO + + - If yes, provide URL: + + - Is there evidence that this vulnerability is being actively exploited? YES | NO + + - If yes, then provide URL/evidence. + + - I plan to publicly disclose this vulnerability YES/NO + + - ...on this date (Please include your time zone.) + - ...at this URL + +!!! question "What are your contact details?" + + - Name + - Organization + - Email + - PGP Public Key (ASCII Armored or a URL) + - Telephone + - May we provide your contact information to third parties? YES | NO + - Do you want to be publicly acknowledged in a disclosure? YES | NO + +!!! question "Any Additional Information?" + + - Vendor Tracking ID, CERT Tracking ID, or CVE ID if known: + - Additional Comments: diff --git a/docs/stylesheets/admonitions/cvdguide.css b/docs/stylesheets/admonitions/cvdguide.css new file mode 100644 index 0000000..2527c79 --- /dev/null +++ b/docs/stylesheets/admonitions/cvdguide.css @@ -0,0 +1,17 @@ +:root { + --md-admonition-icon--cvdguide : url('data:image/svg+xml;charset=utf-8,') +} +.md-typeset .admonition.cvdguide, +.md-typeset details.cvdguide { + border-color: #C41230; +} +.md-typeset .cvdguide > .admonition-title, +.md-typeset .cvdguide > summary { + background-color: rgba(178,45,53, 0.1); +} +.md-typeset .cvdguide > .admonition-title::before, +.md-typeset .cvdguide > summary::before { + background-color: #C41230; + -webkit-mask-image: var(--md-admonition-icon--cvdguide); + mask-image: var(--md-admonition-icon--cvdguide); +} \ No newline at end of file diff --git a/docs/stylesheets/admonitions/ssvc.css b/docs/stylesheets/admonitions/ssvc.css new file mode 100644 index 0000000..9d4114d --- /dev/null +++ b/docs/stylesheets/admonitions/ssvc.css @@ -0,0 +1,17 @@ +:root { + --md-admonition-icon--ssvc : url('data:image/svg+xml;charset=utf-8,') +} +.md-typeset .admonition.ssvc, +.md-typeset details.ssvc { + border-color: #C41230; +} +.md-typeset .ssvc > .admonition-title, +.md-typeset .ssvc > summary { + background-color: rgba(178,45,53, 0.1); +} +.md-typeset .ssvc > .admonition-title::before, +.md-typeset .ssvc > summary::before { + background-color: #C41230; + -webkit-mask-image: var(--md-admonition-icon--ssvc); + mask-image: var(--md-admonition-icon--ssvc); +} diff --git a/docs/stylesheets/admonitions/vultron.css b/docs/stylesheets/admonitions/vultron.css new file mode 100644 index 0000000..1259970 --- /dev/null +++ b/docs/stylesheets/admonitions/vultron.css @@ -0,0 +1,17 @@ +:root { + --md-admonition-icon--vultron : url('data:image/svg+xml;charset=utf-8,') +} +.md-typeset .admonition.vultron, +.md-typeset details.vultron { + border-color: #C41230; +} +.md-typeset .vultron > .admonition-title, +.md-typeset .vultron > summary { + background-color: rgba(178,45,53, 0.1); +} +.md-typeset .vultron > .admonition-title::before, +.md-typeset .vultron > summary::before { + background-color: #C41230; + -webkit-mask-image: var(--md-admonition-icon--vultron); + mask-image: var(--md-admonition-icon--vultron); +} diff --git a/docs/stylesheets/cmu_color_scheme.css b/docs/stylesheets/cmu_color_scheme.css new file mode 100644 index 0000000..1d82685 --- /dev/null +++ b/docs/stylesheets/cmu_color_scheme.css @@ -0,0 +1,5 @@ +[data-md-color-scheme="cmu"] { + --md-primary-fg-color: #C41230; + --md-primary-fg-color--light: #E0E0E0; + --md-primary-fg-color--dark: #6D6E71; +} diff --git a/docs/stylesheets/extra.css b/docs/stylesheets/extra.css new file mode 100644 index 0000000..83fe644 --- /dev/null +++ b/docs/stylesheets/extra.css @@ -0,0 +1,8 @@ +@import "cmu_color_scheme.css"; +@import "admonitions/ssvc.css"; +@import "admonitions/vultron.css"; +@import "admonitions/cvdguide.css"; + + + + diff --git a/docs/topics/index.md b/docs/topics/index.md new file mode 100644 index 0000000..6d4824e --- /dev/null +++ b/docs/topics/index.md @@ -0,0 +1,20 @@ +# Understanding CVD + +While we provide more practical guidance in the [How To](../howto/index.md) section, +this section provides a more abstract understanding of Coordinated Vulnerability Disclosure (CVD). +This section is intended for those who want to understand the principles, roles, and phases of CVD. + +```mermaid +--- +title: CVD Overview +--- +flowchart LR +Principles -->|guide| Roles +Roles -->|perform| Phases +Principles -->|support| Phases + +``` + +{% include-markdown "./principles/index.md" heading-offset=1 %} +{% include-markdown "./roles/index.md" heading-offset=1 %} +{% include-markdown "./phases/index.md" heading-offset=1 %} diff --git a/docs/topics/phases/deployment.md b/docs/topics/phases/deployment.md new file mode 100644 index 0000000..c7cecf7 --- /dev/null +++ b/docs/topics/phases/deployment.md @@ -0,0 +1,239 @@ +# Deployment + +Although we tend to think of the CVD process as ending with the disclosure of a vulnerability, if the fix is not +deployed the rest of the exercise is futile. +A fix that is quietly posted to a website and not well advertised is almost useless in protecting users from vulnerabilities. + +Let's say that again, but this time with a box around it: + +!!! warning "CVD isn't over until the fix is deployed" + + Vendors make fixes available. + But systems are not secure until those fixes are deployed. + +Deploying fixes often implies provoking users, customers, and deployers to take positive action. +Many software products are used by non-technical users. +These users are often unaware of how to take remediative or mitigating action for a vulnerability. +A vendor's disclosure plan should consider how to reach the widest audience with actionable advice. + +It is worth remembering that public awareness is just *one* way to achieve widespread deployment. +The following are a few examples of others, in approximate order according to how often we encounter them. + +## Automatic updates + +Vendors might choose to design their software with automated updates as part of their deployment strategy. +Products with secure automatic updates provide a good way to get a patch deployed quickly to a wide audience. + +!!! note inline end "Software Telemetry and Privacy" + + Software telemetry is not without [privacy concerns](https://www.theregister.com/2023/05/17/googles_go_data_collection/), but further discussion of that topic is out of scope here. + +However, not all users are able or willing to use automatic updates, so it is still important for vendors to draw attention to their fixes. +Vendors should strive to implement easy and secure update methods in their products. +In addition to improving deployment efficiency, automatic updates provide an opportunity for vendors to have visibility into the deployment status across their customer base via telemetry. +In situations where automated deployment is not possible, the vendor's disclosure plan should be specific about how to spread the word of a new patch as quickly as possible. + +## Single Instance Software + +Vendors who provide Software-as-a-Service can often just deploy fixes directly to their own infrastructure since they are both the developer and deployer of the software. +In this case SAAS need not be restricted to just subscriber-based services, it can include infrastructure (i.e., cloud) or public-facing websites regardless of their size. +The distinguishing factor is that the vendor is both the originator of the fix and the deployer. +Many bug bounty programs or Vulnerability Disclosure Programs (VDPs) exist in this space. +For example, many of the reports received by the DoD's VDP are for this kind of vulnerability, often involving custom-developed web sites or misconfigured web servers that can be fixed directly without user involvement. + +## Close-hold software communities + +As mentioned in [Publishing](publishing.md), Vendors may choose to directly notify deployers (as opposed to public announcements) if they have the ability to do so. +This kind of private notification may be appropriate when the deployers are well known to the vendor, as might be the case in a closely-held bespoke software package. +For example, software developers for highly specialized equipment are often in direct communication with both the equipment makers and its deployers just as a matter of everyday business. +Such vendors can be well-positioned to reach their entire deployment base via private channels. + +!!! tip "Give Critical Infrastructure a Head Start When Possible" + + Some vulnerabilities are pervasive in the very infrastructure required + for the patches or information about the vulnerability to be + distributed. + Other vulnerabilities + may disproportionately affect critical infrastructure services that + directly impact public safety -- for example the water system, power + grid, or hospital medical gear. All these types of systems often require + their operators to perform extra testing and impact analysis prior to + deploying patches. It's not always practical to do so, but when + possible, providing these kinds of deployers with advance notification + of either the existence of the vulnerability or access to the fix can + reduce the risk faced by the public and improve outcomes. + +!!! example "Vulnerabilities in Internet Infrastructure" + + Vulnerabilities in foundational network protocols, + problems such as denial of service against backbone routers, remote + code execution on Domain Name System (DNS) servers, or virtualization + escapes in cloud services serve as examples. + + - [VU#498440](https://www.kb.cert.org/vuls/id/498440/) _Multiple TCP/IP implementations may use + statistically predictable initial sequence numbers_ + - [JSA10883](https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10883&cat=SIRT_1&actp=LIST) _2018-10 Security Bulletin: Junos OS: Receipt of a + specifically crafted malicious MPLS packet leads to a Junos kernel + crash (CVE-2018-0049)_ + - [VU#196945](https://www.kb.cert.org/vuls/id/196945/) _ISC BIND 8 contains buffer overflow in transaction + signature (TSIG) handling code_ + - [XSA-213](https://xenbits.xen.org/xsa/advisory-213.html) _Xen Security Advisory CVE-2017-8903 / XSA-213; version 3; + x86: 64bit PV guest breakout via pagetable use-after-mode-change_ + +!!! tip "Amplify the Message" + + Sometimes it is necessary to draw more attention to a problem or fix. + Critical vulnerabilities, including those that are already being + exploited or are highly likely to be exploited, may warrant attracting + attention beyond merely publishing a document on the vendor's support + site. In such cases, additional measures should be taken to draw + attention to the existence of the vulnerability or the availability of + its fix. (See also [Public Awareness](public_awareness.md)) + + Vendors should consider using: + + - Announcements via social media. Many defenders use services like + Twitter or Reddit as part of their daily situation awareness + process, routinely sharing useful links and references with each + other. + - Mass media such as press releases, press conferences, and media + interviews + - Working with a coordinator or government agency to draw attention to + a vulnerability or its fix. In particular, National CSIRTs can often + provide advice or assistance with publicity on important issues. + +## Post-Publication Monitoring + +Once a vulnerability and/or its fix has been disclosed, both vendors and +reporters should look for feedback concerning any problems with either +the documentation or the fix. In some cases, this can take the form of +technical monitoring (e.g., monitoring download logs from the vendor's +update service, checking inventories of deployed system versions, or +even scanning) to ascertain the rate of defender deployments. Even if +such technical monitoring is not possible, not permitted, risky, costly, +or otherwise impractical, it is usually possible to monitor for user +feedback via support requests, online discussions, and so forth. + +In the event of slow uptake of the fix, additional effort might be +warranted to call attention the vulnerability (for example, using social +media). + +It is also possible that the mitigation advice is incorrect, or may not +apply to all scenarios. Therefore the vendor and reporter should monitor +for public discussion or reports of problems, so that the disclosure +advisory and remediation information can be updated as necessary. +Remember, the goal for remediation is to fix vulnerable product +instances or at least reduce the impact of the vulnerability. +Consequently, if a significant portion of the vulnerable product +instances have not been remediated, that goal has not been achieved. + +!!! note "CVD Goes to Washington" + + In an unexpected turn of events following the publication of this Guide, + we were [called + on](https://web.archive.org/web/20230112063739/https://republicans-energycommerce.house.gov/wp-content/uploads/2018/07/071718-SEI-Spectre-Meltdown.pdf) by the [US House Committee on Energy and + Commerce](https://energycommerce.house.gov/) and the [Senate Committee on Commerce, Science, and + Transportation](https://www.commerce.senate.gov/public/) to address + [concerns](https://www.commerce.senate.gov/public/index.cfm/hearings?ID=77835497-EC96-41E8-B311-5AF789F38422) regarding the coordinated disclosure of the Meltdown and + Spectre vulnerabilities in early 2018. In particular, the committees + were concerned about the timing of patch availability and deployment + relative to the public disclosure of these vulnerabilities. + + !!! quote + + In their responses to the Committees' letters, many of the companies + explained that it is industry best practice to embargo vulnerability + information amongst the smallest possible group of stakeholders during + CVDs to prevent "bad actors" from learning of the vulnerability or + vulnerabilities before they have been corrected. Many of the companies + further advised that they followed or otherwise cited the CVD protocol + or guidance provided by the CERT Coordination Center (CERT/CC). In + addition, many respondents further argued that it is critical to do so + to ensure that patches are "in place," "delivered," or + "implemented" prior to widespread public disclosure. As a company or + user is not protected from a given vulnerability until an appropriate + patch is "in place," "delivered," or "implemented," we agree + that sound CVD strategies would seek to limit disclosure of + vulnerability information before stakeholders are able to apply + patches. Such a practice allows for the best protection of the + end user--typically, consumers. + + The committees went on to note: + + !!! quote + + However, based on the responses to our letters and information + provided during company briefings, questions remain + regarding\...whether companies used precise terminology in describing + the *availability, *not *application*, of patches. Companies outside + the core group needed time to test and successfully implement patches, + and the availability of a patch and the application of a patch are not + the same. The fact that a patch or other mitigation is "available" + simply means that it exists and is ready for a company or individual + to use. But when a patch or other mitigation is described as "in + place," "delivered," or "implemented," the distinction implies + that companies and individuals have retrieved that patch and actually + applied it to their systems. + + In our + [response](https://web.archive.org/web/20200810085618/https://republicans-energycommerce.house.gov/wp-content/uploads/2018/08/CERT-Response-MultiParty-CVD-Congressional-Letter.pdf), we agreed. The relevant section of our reply is + reproduced below. + + ## Patch Availability is not Patch Deployment + + The committees' letter asks "\...whether companies used precise + terminology in describing the availability, not application, of patches" + and points out "\...the misapplication of such terms as 'in place' and + 'available' when used to describe the status of vulnerability patches." + + CVD guidance can be more clear in both terminology and the boundary + between the phases of patch availability and patch deployment. And while + we agree that vendors should take care not to overstate the status of + patch deployment, the best many vendors can do today is to make patches + available, along with sufficient vulnerability information for users to + make informed patching and other risk decisions.^1^ Ultimate + responsibility for installing patches often falls to + deployers,^2^ including end users. + + While we appreciate the committees' desire that "sound CVD strategies + would seek to limit disclosure of vulnerability information before + stakeholders are able to apply patches," our experience indicates that + it is impractical to privately notify all affected stakeholders without + public disclosure. Thus, public disclosure is usually the best practice + to inform affected parties—including end users—who may need to take + action in order to apply patches to their software and devices. + + The committees' letter correctly points out that the deployers' need to + test patches "can lead to a lag time of weeks or months before a patch + is applied." We note that in the extreme, this lag time can become + indefinite for reasons including: + + - Some deployers (including many end users) will remain unaware of the + availability of patches, or will lack the technical capability to + deploy them successfully. + - Long or complex supply chains for patch distribution may result in + patches issued by an originating vendor not making it through to the + downstream vendors' products in a timely manner. + - Some deployers will intentionally choose to accept the risk and not + apply the patch at all. The decision to apply patches is a risk + management decision. + + For especially pervasive vulnerabilities such as Meltdown and Spectre, + there is no clear optimal solution to balancing the diverse operational + cadence across such a wide range of industries (including critical + infrastructure sectors) with the need for timely public disclosure. It + may be that the best we can expect is for consistent, accurate, + thorough, and timely information to be provided in support of defender + decisions. + + ------------------------------------------------------------------------ + + 1. Some products have secure, robust, and automated patch deployment + features. Software-as-a-service (SaaS) and other cloud services can + typically be updated by providers, requiring little if any action by + end users. + 2. By "deployers" we mean those responsible for choosing if, when, and + how to install patches or perform other mitigating or compensating + actions. Deployers can include system administrators, vulnerability + management systems, vendors with the ability to push patches, and + end users who must take manual action. diff --git a/docs/topics/phases/discovery.md b/docs/topics/phases/discovery.md new file mode 100644 index 0000000..eeb5795 --- /dev/null +++ b/docs/topics/phases/discovery.md @@ -0,0 +1,45 @@ +# Discovery + +Aside from the simplest applications, software development is difficult, +complex, and prone to error. As a result, the likelihood that any given +software-based product or component is free of vulnerabilities is +extremely low. For vendors, this implies the need to create a response +capability to handle vulnerability reports, whether those reports come +from sources internal or external to the vendor. + +!!! question "Why Look for Vulnerabilities?" + + Ultimately, we can't fix vulnerabilities we don't know about. While + software engineering best-practices, code audits, testing (including + fuzzing), and application security testing are important parts of the + development lifecycle, security research is important for rooting out + hidden vulnerabilities. Some organizations may have in-house expertise + to find and identify security vulnerabilities, but most will not. For + some vendors, encouraging independent vulnerability finders may be the + only way to stay on top of the latest trends in vulnerability research + and exploitation techniques. + +!!! quote "Donald Rumsfeld on [Unknown Unknowns](https://en.wikipedia.org/wiki/There_are_unknown_unknowns)" + + Reports that say that something hasn’t happened are always interesting to me, + because as we know, there are known knowns; there are things we know we know. + We also know there are known unknowns; that is to say we know there are some + things we do not know. But there are also unknown unknowns – the ones we don’t + know we don’t know. + +!!! tip "Be Wary of Null Results" + + Many organizations hire application security testers or code auditors to + look for vulnerabilities. While such testing is certainly important and + commendable, it is important to understand that absence of evidence is + not always evidence of absence. + Rumsfeld's point applies here. + + A clean audit or pen test report should not be taken as + evidence that the software is free of vulnerabilities. All + software-based systems have problems we're not even aware of and so we + don't even know to look for them. Because such vulnerabilities may + exist and can be exploited without warning, vendors and deployers should + establish their vulnerability response capability in preparation for this eventuality. + +{% include-markdown "../../howto/preparation/avoid_risk.md" heading-offset=1 %} diff --git a/docs/topics/phases/index.md b/docs/topics/phases/index.md new file mode 100644 index 0000000..8410c6e --- /dev/null +++ b/docs/topics/phases/index.md @@ -0,0 +1,102 @@ +# Phases of Coordinated Vulnerability Disclosure + +Below, we adapt a version of the +[ISO/IEC 30111:2019 Information technology—Security techniques—Vulnerability handling processes](https://www.iso.org/standard/69725.html) +with more phases to better describe what we have seen at the CERT/CC + +
+ +- :material-magnify: [**Discovery**](discovery.md) + + --- + A researcher (not necessarily an academic one) discovers a vulnerability by using one of numerous tools and processes. + +- :material-message-alert: [**Reporting**](reporting.md) + + --- + A researcher submits a vulnerability report to a software or product vendor, or a third-party coordinator if necessary. + +- :material-message-check: [**Validation**](validation.md) and :material-format-list-numbered: [**Prioritization**](prioritization.md) + + --- + The analyst validates the report to ensure accuracy before action can be taken and prioritizes reports relative to others. + +- :material-code-block-braces: [**Remediation**](remediation.md) + + --- + A remediation plan (ideally a software patch, but could also be other mechanisms) is developed and tested. + +- :material-newspaper: [**Public Awareness**](public_awareness.md) + + --- + The vulnerability and its remediation plan is disclosed to the public. + +- :material-server-network: [**Deployment**](deployment.md) + + --- + The remediation is applied to deployed systems. + +
+ +!!! info "Vulnerability Handling Process Models" + + There have been a number of proposed models of the CVD process that have slightly varying phases. Some of the most notable include: + + - 2002 Christey and Wysopal [Responsible Vulnerability Disclosure Process](https://datatracker.ietf.org/doc/draft-christey-wysopal-vuln-disclosure/) + - 2004 National Infrastructure Advisory Council [Vulnerability Disclosure Framweork](https://www.dhs.gov/xlibrary/assets/vdwgreport.pdf) + - 2018 ISO/IEC 29147:2018 [Information technology -- Security techniques -- Vulnerability disclosure](https://www.iso.org/standard/72311.html) + - 2019 ISO/IEC 30111:2019 [Information technology -- Security techniques -- Vulnerability handling processes](https://www.iso.org/standard/69725.html) + +## Who Does What? + +Extending the diagram from the [Roles in CVD](../roles/index.md) page, +we can see how the roles interact in the CVD process. + +```mermaid +--- +title: CVD Role Relationships +--- +flowchart TB + subgraph C[Coordination] + direction LR + subgraph A[Often Same Entity] + Reporter([Reporter]) + Finder([Finder]) + end + Vendor([Vendor]) + subgraph B[Sometimes Included] + Coordinator([Coordinator]) + Deployer([Deployer]) + end + + end + + Finder -->|shares vul
info with| Reporter + Reporter -->|reports
vul to| Vendor + Reporter -.->|provides vul
info to| Deployer + Reporter -.->|reports
vul to| Coordinator + + Vendor -->|coordinates
with| Reporter + Vendor -.->|coordinates
with| Coordinator + Vendor -->|provides vul info
and/or patch to| Deployer + + Coordinator -.->|coordinates
with| Vendor + Coordinator -.->|coordinates
with| Reporter + Coordinator -.->|provides vul
info to| Deployer + + Deployer -->|provides
feedback to| Vendor + + C -->|publish| Public([Public]) +``` + +A mapping of CVD phases to CVD roles is provided in the following table. + +| Role →
Phases ↓ | Finder | Reporter | Vendor | Coordinator | Deployer | +|-------------------------------|-----------------------|-------------------------------------------------|------------------------------------------------|---------------------------------------------------------------|-----------------------------------| +| Discovery | Finds Vulnerabilities | - | - | - | - | +| Reporting | Prepares report | Reports vuls to vendor(s) and/or coordinator(s) | Receives reports | Receives reports | - | +| Validation | - | - | Validates reports received | Validates reports received | - | +| Prioritization | - | - | Prioritizes reports for response | Prioritizes reports for response | Prioritizes fixes for deployment | +| Remediation | - | Confirms fix | Prepares patches, develops advice, workarounds | Coordinates multiparty response, develops advice, workarounds | - | +| Public Awareness | Publishes advisory | Publishes advisory | Publishes advisory | Publishes advisory | Receives advisory | +| Deployment | - | - | - | - | Deploys fix or mitigation | diff --git a/docs/topics/phases/prioritization.md b/docs/topics/phases/prioritization.md new file mode 100644 index 0000000..e896a30 --- /dev/null +++ b/docs/topics/phases/prioritization.md @@ -0,0 +1,32 @@ +# Prioritization + +Once the receiver of a report has [validated](validation.md) the report +as in scope, credible, and valid, the next question is how to allocate resources to the report. +Not every report can be addressed immediately, so prioritization is necessary. + +At the most basic level, prioritization can be thought of as a simple binary decision: + +```mermaid +flowchart TD + when[When do we act?] + now[Now] + defer[Not now] + when --> now + when --> defer +``` + +In practice, however, prioritization can be more complex. + +!!! ssvc "Stakeholder-Specific Vulnerability Categorization (SSVC)" + + The CERT/CC's [Stakeholder-Specific Vulnerability Categorization](https://certcc.github.io/SSVC) (SSVC) + provides a method for developing vulnerability management decision models + that are tailored to the specific needs of different stakeholders. + Much of what we have to say about prioritization is already covered in that documentation. + +!!! question "Who Receives Reports?" + + The receiver of a report is typically a [vendor](../roles/vendor.md), but it could also be a + [coordinator](../roles/coordinator.md) or a [deployer](../roles/deployer.md). + +{% include-markdown "../../howto/coordination/prioritization.md" heading-offset=1 %} diff --git a/docs/topics/phases/public_awareness.md b/docs/topics/phases/public_awareness.md new file mode 100644 index 0000000..47c1310 --- /dev/null +++ b/docs/topics/phases/public_awareness.md @@ -0,0 +1,213 @@ +# Public Awareness + +Public awareness of a vulnerability can be intentionally used to promote deployment of the fix. +However, that is not the only reason to draw the public's attention to the existence of a vulnerability. +Other reasons include providing a history of fixed security flaws, or facilitating research into the root causes of vulnerabilities. + +For defenders, deploying patches requires effort and is often avoided +unless there is sufficient justification. Therefore it is important to +provide at least a brief description of the vulnerability in the release +notes for the updated code. Knowledge of the existence of a +vulnerability is often the key driver causing patches to be deployed. + +## Disclosure Decisions + +Even within the CVD process, there are still many decisions to be made +about the disclosure process. The audience, timing, and amount of +information released can vary because of a number of factors. These +choices might even vary from report to report, depending on the impact +and consequences of a particular vulnerability. + +Generally, finders, reporters, vendors, and coordinators should consider +the following questions in establishing their policies and practices: + +
+ +!!! question "Should you disclose at all?" + + Generally, the answer will be yes, + but there may be factors that influence this decision. For example, + some vulnerabilities, if exploited, could place lives in danger or + cause severe socioeconomic harm. As a result, it may be prudent for + reports of such vulnerabilities to be held indefinitely until the + population of vulnerable systems has been reduced through patching + or obsolescence. However, any decision to defer disclosure should be + considered provisional or contingent on the continued absence of + evidence of exploitation or adversarial knowledge of the + vulnerability. + +!!! question "What information will you disclose?" + + For example, will you + publish all information about the vulnerability, including proof of + concept code, or will you only release a brief description of the + problem and a remediation? Generally speaking, there is a minimum + amount of information required in order for a vulnerability report + to be useful. Recall that the point of disclosure is to provoke some + action, most often by deployers or any downstream vendors who were + not already involved in the coordination process. If the details + provided to the recipient are insufficient to cause that action to + be taken, the disclosure process will not succeed. + +!!! question "To whom will you disclose?" + + In most cases, the disclosure should + be made publicly. However, in some scenarios the disclosure may be + to a specific limited group. For example, if the pool of users is + small and the vendor reaches out to every impacted user, a public + disclosure may be unnecessary. + +!!! question "Via what channel(s) will you disclose?" + + Will the vulnerability + information be published on the vendor's website? The reporter's + blog? One or more mailing lists? + Will you draw attention to it on social media? + + There are pros and + cons to most of these options that must be weighed. When available, + an organization's communications or public relations groups should + be involved in planning for the disclosure process. While it is + usually neither possible nor practical to have every CVD case flow + through them, leveraging their expertise in planning and developing + the CVD capability can improve the process + considerably. + +
+ +!!! question "What is your expectation of others in disclosing further (or not)?" + + Be sure to discuss your expectations with all stakeholders and be + prepared to negotiate. + +!!! tip "Three Key Questions for Vendors" + + Vendors in particular will need to address three main questions in + providing vulnerability and fix information to defenders: + + - What information should be provided about the vulnerability? + - Where should this information be provided? + - What, if any, additional measures should be taken to draw attention + to the existence of the vulnerability or the availability of its + fix? + +!!! tip "When to Engage a Coordinator" + + In multiparty CVD, private notifications to other vendors and even + public disclosures by individual vendors may not sufficiently raise + awareness or accurately reflect the scope of a vulnerability. Because of + the role they play in conveying information to a broad audience of + system deployers, trusted third parties (non-vendors) such as DHS CISA, + the CERT/CC, or other coordinators can help notify affected vendors, + facilitate technical analysis of the vulnerability and its impact, and + amplify communications to the public. When vendors provide advance + notice of major vulnerabilities to the coordinator community, it allows + the various coordinating organizations to prepare accurate remediation + instructions for system deployers, and to publish that information in + synchronization with the vendors' release of the patches. When that + advance notification does not occur sufficiently early, as in the case + of [Meltdown and Spectre](https://www.defenseone.com/technology/2018/02/how-long-did-us-government-know-about-spectre-and-meltdown/145776/), coordinators may be in a rush to + understand the issue while preparing their advisories, leading to + erroneous or inadequate advice to their constituencies. + +## Vulnerability Identifiers + +Many vulnerability reports can be similar, and sometimes a vendor or +coordinator might receive multiple reports of similar vulnerabilities at +the same time. +Sometimes this is due to [independent discovery](../../howto/coordination/independent_discovery.md). +Other +times it reflects a report traversing multiple paths to arrive at its +destination within the CVD process. This is fairly common in cases where +a vulnerability affects products from multiple vendors. Using a common +identifier improves coordination as it ensures that all coordinating +parties can keep track of the issue. + +!!! example "Common Vulnerability and Exposure (CVE) IDs" + + The most common identifier in use today is the [CVE ID](https://www.cve.org), + which is + meant as a globally unique identifier for a public vulnerability report. + CVE IDs can be obtained from the CVE Project at MITRE or one of several + [CVE Numbering Authorities](https://www.cve.org/PartnerInformation/ListofPartners) + (CNAs) established by MITRE—typically the + vendors of common software products themselves. Both reporters and + vendors can request a CVE ID, but reporters should first check if the + vendor they are coordinating with is already a CNA. This identifier + should be included in any pre-disclosure shared drafts, so that all + parties are aware of the common identifier. + +!!! warning "ID Assignments Trigger Downstream Workflows" + + Many system deployers use vulnerability scanning tools to discover + systems on their network that need to have patches applied. In turn, + many vulnerability scanning tools depend on public vulnerability + databases such as NVD. Furthermore, NVD entries are largely dependent on + CVE ID assignments. + + ```mermaid + --- + title: CVE IDs in the Vulnerability Response Flow + --- + flowchart LR + cna[CVE Numbering
Authority] + cve[CVE ID] + nvd[National
Vulnerability
Database] + vst[Vulnerability
Scanning
Tools] + deployer[System
Deployer] + cna -->|assigns| cve + cve -->|ingested by| nvd + nvd -->|is data source to| vst + vst -->|scan findings| deployer + nvd -->|triggers response process| deployer + ``` + + When vendors issue updates without acquiring CVE IDs + for the vulnerabilities they address, the patch can go unnoticed by the + vulnerability databases, scanning tools, and deployers. Therefore we + strongly recommend that vendors acquire as many vulnerability IDs as + necessary to clearly indicate which vulnerabilities are fixed by + specific patches. + +!!! warning "Avoid Silent Fixes" + + A **silent fix** occurs when the vendor knows about and fixes the vulnerability + but fails to mention the vulnerability's existence in the subsequent release + notes accompanying the new version. + As a result, silent fixes are far less likely to be widely deployed than + ones that are clearly described. + +!!! warning "Product Versions Should Increment After Fixes" + + A related issue arises when vendors fail to increment their product + version numbers when issuing a fix for one or more vulnerabilities. This + makes it much harder for coordinators, vulnerability database providers, + vulnerability scanning tool vendors, and deployers to differentiate + systems affected by a vulnerability from those that are not. + +## Prepare and Circulate a Draft + +Prior to public announcement of a vulnerability document, we find it +helpful to circulate a draft document describing the vulnerability to +give CVD participants an opportunity for discussion and commentary. + +At a minimum, a draft advisory should be shared between the reporter and +vendor to reduce the likelihood of either party being taken by surprise. +Ideally, both parties should use this documentation to coordinate how much +information is being released, and what future expectations might exist. +Both parties also have the opportunity to correct erroneous information, +as well as verify that credit for discovering or reporting the +vulnerability is given to the correct person or organization. If +multiple vendors are affected, or there are affected downstream vendors +making use of the vulnerable software, it can be useful to share a draft +with some or all of the affected vendors for even more feedback. Be sure +to also discuss what channels to use for publication and disclosure. + +!!! tip "Traffic Light Protocol" + + The Traffic Light Protocol (TLP) may be useful when sharing draft + information. We discuss applications of TLP to CVD in [OpSec](../../howto/operation/opsec.md). + +!!! tip "Vulnerability Disclosure Document" + + Examples of vulnerability disclosure documents are provided in the Reference section under [Advisory](../../reference/simple_advisory.md). diff --git a/docs/topics/phases/publishing.md b/docs/topics/phases/publishing.md new file mode 100644 index 0000000..fa8e93a --- /dev/null +++ b/docs/topics/phases/publishing.md @@ -0,0 +1,65 @@ +# Publishing + +Once the [draft circulation](public_awareness.md) phase is complete, the next step is +publishing the vulnerability document to whatever channels have been +identified during previous phases. + +Some vendors have a specific website that lists all their security +advisories to date. +Others might email the disclosure to a user mailing list or a security mailing list such as [Full Disclosure](https://seclists.org/fulldisclosure/). + +Reporters often choose to publish their findings +in a presentation or paper, or post it to a mailing list or blog. +A common goal for reporters in the CVD process is to synchronize +their publication with the vendor's response. As a result, +near-simultaneous publication occurs quite often. + +It is generally courteous for the vendor and reporter to contact each +other after disclosure to inform one another that the disclosure went +through as planned and provide URLs to the published +documents. + +## Where to Publish + +!!! note inline end "Public Information is not the Same as Publicity" + + Information about a vulnerability can be _available_ to the public without it being _publicized_. + Examples include: + + - A commit comment in a code repository for an open source project might indicate that a vulnerability has been fixed + - An exploit might be made available on a public web site without being associated with a vulnerability ID or patch release + - A binary diff of two released versions of the same software can be sufficient for an analyst to recognize that a vulnerability was fixed + + In each of these cases, the existence of the vulnerability should be considered to be public information, + but these fall short of being considered *publicized*. + If the goal of the CVD process is for the fixes for vulnerable software to be *deployed*, + then simply making the information public is insufficient -- it must be *publicized*. + +Publicly disclosing the existence of a vulnerability and the +availability of its fix is usually considered to be the primary goal of +the CVD process. + +Vendors will often provide vulnerability information: + +- On the vendor's public website. Many vendors offer a + security-focused section within the support section of their online + offerings. +- To a public mailing list or a vendor-specific list + +Vendors of bespoke software or products with highly focused customer +bases are sometimes reasonably confident that they can reach their +affected users directly. + +These vendors often publish vulnerability and fix information: + +- On a customer-only site +- Via a customer support mailing list +- By individually notifying customers, for example through the + technical sales channel + +However, even with a well-organized customer contact database, it can be +difficult for a vendor to be certain that all relevant decision makers +are reached in a timely manner. Hence, we recommend that vendors publish +at least basic vulnerability and fix announcements to their public +website in addition to whatever direct customer contact communications +they provide. diff --git a/docs/topics/phases/remediation.md b/docs/topics/phases/remediation.md new file mode 100644 index 0000000..9911275 --- /dev/null +++ b/docs/topics/phases/remediation.md @@ -0,0 +1,70 @@ +# Analysis and Remediation + +After an initial assessment of the vulnerability is complete, it's time to work toward remediation or mitigation. + +!!! info inline end "DoDI 8531.01 DoD Vulnerability Management Definitions" + + We follow the DoD's [definitions](https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/853101p.pdf) of _remediation_ and _mitigation_: + + - **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 + +Vendors can remediate vulnerabilities by providing a fix or they can develop mitigation instructions as an interim solution. +The sequence of tasks tends to include identifying and isolating the vulnerability in the code; changing the code to eliminate the vulnerability; testing the changes, packaging the changes for distribution; and distributing the updated product. +While the details of how to do this are often specific to the product as well as the vendor organization and its development process and are thus outside the scope of this document, we review each step in this section. + +Of course, the actual remediation or mitigation of deployed systems is usually not entirely under the control of the vendor. +We defer that discussion until [Public Awareness](public_awareness.md) and [Deployment](deployment.md). + +## Isolate the Problem + +Once a vulnerability report has been received and validated, it must be added into the work queue for the development team to isolate the underlying problem. +This often requires input from developers knowledgeable in the code in order to precisely define the problem and understand its impacts. + +!!! tip "Multiple Paths to Exploitation" + + Often a report will describe a single path to exploit a vulnerability, yet there may be other ways for an attacker to reach the same code and exploit it a different way. + This makes it necessary for the developers and analysts responsible for fixing the code to explore the potential for other avenues of exploitation before zeroing in on the specific conditions found in the original report. + +!!! tip "Vulnerability in Multiple Codebases" + + There is also the risk that the vulnerable code or component has been reused elsewhere. + We have encountered vulnerabilities in multiple codebases that arose because a single developer worked on each project, copying the same vulnerable code into each of them. + +## Notify Others + +In the course of analyzing a vulnerability report to isolate the problem, CVD participants might discover that the problem described in the report affects code developed by others. + +!!! example "Expanding from CVD to MPCVD" + + A Vendor might receive a report in one of their products, but upon further investigation they realize that the bug is actually in a library that their product depends on. + As a result, the Vendor will need to contact the library vendor in order to coordinate fixes to both products. + This is one way in which a CVD case becomes a MPCVD case. + +Figuring out what other products and components are affected by a vulnerability involves understanding the software +supply chain, and often requires a degree of software component analysis in order to ferret out the other products +and vendors that might be affected. + + + +## Fix the Problem + +Reporters and finders should recognize that developing, testing, and preparation of patches for deployment often requires some time. +A vendor acting in good faith to ferret out the vulnerability and fix it thoroughly should usually be granted some leeway. +A well-tested patch that is issued later is preferable to a prematurely released patch that creates further problems. + +!!! tip "Communication is Key" + + We encourage finders, reporters, and vendors to communicate expectations early and often with respect to the status + of the fix creation process as long as a vendor is responsive. + +## Mitigate What You Cannot Fix + +In most cases, knowledge of a vulnerability leads the vendor to create and issue a fix to correct it. +As a stopgap in scenarios where it may not possible to develop a timely fix, a vendor or third party will sometimes +provide advice on actions that can be taken to mitigate the effects of the vulnerability. +Sometimes this advice is as simple as instructions for disabling the affected features of the system. +In other cases, mitigation advice might include detailed configuration changes to be made by deployers. +However, in nearly all cases a full fix for the vulnerability is preferable to mitigation advice, which should at best +be treated as a temporary solution to the problem. diff --git a/docs/topics/phases/reporting.md b/docs/topics/phases/reporting.md new file mode 100644 index 0000000..e99e7ad --- /dev/null +++ b/docs/topics/phases/reporting.md @@ -0,0 +1,27 @@ +# Reporting + +Anyone who becomes aware of a vulnerability that does not appear to have +been remediated should report the vulnerability to the vendor. One +should not assume that a vendor is aware of a specific vulnerability +unless it has already been publicly reported, whether by the vendor or +elsewhere. The easier it is to report vulnerabilities to a vendor, the +less likely that the vendor will be surprised by vulnerability reports +disclosed directly to the public. + +!!! tip "Advice for Vendors" + + Vendors need a mechanism to receive vulnerability reports from others. + This reporting mechanism should be easy enough to use that it encourages + rather than discourages reports. It can be as simple as a dedicated + email address for reporting security issues, a secure web form, or a bug + bounty program. Aside from the technical aspects of encouraging + reporting, vendors can also provide reporters with other [incentives](../principles/incentivize_behavior.md). + +!!! info "Report Template" + + An example of a template for a vulnerability report, based on the + CERT/CC's own [Vulnerability Reporting Form](https://kb.cert.org/vuls/report/) (VRF), is provided + in the [References](../../reference/simple_vrf.md) section. + Vendors that require additional information to validate reports should + clearly document their specific requirements in their vulnerability + disclosure policy, reporting form, or process description. diff --git a/docs/topics/phases/validation.md b/docs/topics/phases/validation.md new file mode 100644 index 0000000..9fedc18 --- /dev/null +++ b/docs/topics/phases/validation.md @@ -0,0 +1,11 @@ +# Report Validation + +Vulnerability reports received from potentially unknown sources may hold +inaccurate information. One of the first tasks for the receiver of a +report is to analyze the report's validity. A vulnerability report is +basically an assertion that some set of conditions exists that permits +an adversary to take some action in support of a goal. But just because +it was reported doesn't make it true. Replication of the salient claims +made in the report is an important step in the case handling process. + +{% include-markdown "../../howto/coordination/validation.md" heading-offset=1 %} diff --git a/docs/topics/principles/avoid_surprise.md b/docs/topics/principles/avoid_surprise.md new file mode 100644 index 0000000..fad07e3 --- /dev/null +++ b/docs/topics/principles/avoid_surprise.md @@ -0,0 +1,18 @@ +# Avoid Surprise + +As with most situations in which multiple parties are engaged in a +potentially stressful and contentious negotiation, surprise tends to +increase the risk of a negative outcome. The importance of clearly +communicating expectations across all parties involved in a CVD process +cannot be overemphasized. + +If we expect cooperation between all parties and stakeholders, we should +do our best to match their expectations of being "in the loop" and +minimize their surprise. Publicly disclosing a vulnerability without +coordinating first can result in panic and an aversion to future +cooperation from vendors and finders alike. + +!!! tip "Future Cooperation is Built on Trust" + + CVD promotes continued cooperation and increases the likelihood that + future vulnerabilities will also be addressed and remedied. diff --git a/docs/topics/principles/ethics.md b/docs/topics/principles/ethics.md new file mode 100644 index 0000000..7fb90f5 --- /dev/null +++ b/docs/topics/principles/ethics.md @@ -0,0 +1,85 @@ +# Ethical Considerations + +!!! info inline end "ethicsfIRST" + + The FIRST Ethics [site](https://ethicsfirst.org/) addresses the following topics: + + - trustworthiness + - coordinated vulnerability disclosure + - confidentiality + - acknowledgment + - authorization + - information + - human rights + - team health + - team ability + - responsible collection + - jurisdictional boundaries + - evidence-based reasoning + +In the security response arena, work toward defining ethical +guidelines is ongoing. The Forum of Incident Response and Security Teams +(FIRST) has established an [Ethics special interest group](https://www.first.org/global/sigs/ethics/) +to develop a [code of ethics](https://ethicsfirst.org/) for its member teams and liaisons. + +!!! quote "FIRST Ethics SIG: Duty of coordinated vulnerability disclosure" + + Team members who learn of a vulnerability should follow coordinated vulnerability disclosure by cooperating with stakeholders to remediate or mitigate the security vulnerability and minimize harm associated with disclosure. Stakeholders include but are not limited to the vulnerability reporter, affected vendor(s), coordinators, defenders, and downstream customers, partners, and users. + + Team members should coordinate with appropriate stakeholders to agree upon clear timelines and expectations for the release of information, providing enough details to allow users to evaluate their risk and take actionable defensive measures." + +We also highlight some ethics advice from related sources. + +## Ethics in Related Professional Societies + +Various computing-related professional societies have established their +own codes of ethics. Each of these has some application to CVD. +While we are not attempting to replicate their ethical guidelines, +we do want to highlight that these codes exist and are relevant to the +work of CVD. + +!!! quote "Association for Computing Machinery (ACM) [Code of Ethics and Professional Conduct](https://www.acm.org/about-acm/acm-code-of-ethics-and-professional-conduct)" + + - Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing. + - Avoid harm. + - Be honest and trustworthy. + - Be fair and take action not to discriminate. + - Respect the work required to produce new ideas, inventions, creative works, and computing artifacts. + - Respect privacy. + - Honor confidentiality. + +!!! quote "Usenix System Administrators' [Code of Ethics](https://www.usenix.org/system-administrators-code-ethics)" + + I will do my best to make decisions consistent with the safety, privacy, and well-being of my community and the + public, and to disclose promptly factors that might pose unexamined risks or dangers. + +## Journalism Ethics + +In many ways, disclosing a vulnerability can be thought of as a form of +journalistic reporting, in that + +!!! quote "American Press Association: [Principles of Journalism](https://americanpressassociation.com/principles-of-journalism/)" + + The central purpose of journalism is to provide citizens with accurate and reliable information they need to function in a free society. + +By analogy, vulnerability disclosure provides individuals and +organizations with the information they need to make the best possible +decisions about their products, their computing systems and networks, +and the security of their information. + +We find the four major principles offered by The Society of Professional +Journalists Code of Ethics to be relevant to CVD as well: + +!!! quote "Society of Professional Journalists [Code of Ethics](https://www.spj.org/ethicscode.asp)" + + - **Seek truth and report it** -- Ethical journalism should be + accurate and fair. Journalists should be honest and courageous in + gathering, reporting and interpreting information. + - **Minimize harm** -- Ethical journalism treats sources, subjects, + colleagues and members of the public as human beings deserving of + respect. + - **Act independently** -- The highest and primary obligation of + ethical journalism is to serve the public. + - **Be accountable and transparent** -- Ethical journalism means + taking responsibility for one's work and explaining one's + decisions to the public. diff --git a/docs/topics/principles/incentivize_behavior.md b/docs/topics/principles/incentivize_behavior.md new file mode 100644 index 0000000..c7ce55b --- /dev/null +++ b/docs/topics/principles/incentivize_behavior.md @@ -0,0 +1,25 @@ +# Incentivize Desired Behavior + +A degree of community outreach is an important part of any CVD process. +Not everyone shares the same values, concerns, perspectives, or even +ethical foundations, so it's not reasonable to expect everyone to play +by your rules. Keeping that in mind, we've found that it's usually +better to reward good behavior than try to punish bad behavior. Such +incentives are important as they increase the likelihood of continued +cooperation between CVD participants. + +!!! example "Incentives in CVD" + + Incentives can take many forms: + + - **Recognition** -- Public recognition is often used as a reward for + "playing by the rules" in CVD. + - **Gifts** -- Small gifts (or "swag") such as T-shirts, stickers, + and so forth give researchers a good feeling about the organization. + - **Money** -- Bug bounties can turn CVD into piece work. + - **Employment** -- We have observed cases where organizations choose + to hire the researchers who report vulnerabilities to them, either + on a temporary (contract) or full-time basis. This is of course + neither required nor expected, but having a reputation of doing so + can be an effective way for a vendor to encourage positive + interactions. diff --git a/docs/topics/principles/index.md b/docs/topics/principles/index.md new file mode 100644 index 0000000..2101f8d --- /dev/null +++ b/docs/topics/principles/index.md @@ -0,0 +1,51 @@ +# Principles of Coordinated Vulnerability Disclosure + +Over the years, the CERT/CC has identified a number of principles that guide our efforts in coordinating vulnerability disclosures and which +seem to be present in many successful CVD programs. +These principles include the following: + +
+ +- :material-safety-goggles: [Reduce Harm](./reduce_harm.md) + + --- + {% include-markdown "./reduce_harm.md" start="" + end="" %} + +- :fontawesome-solid-handshake-angle: [Presume Benevolence](./presume_benevolence.md) + + --- + {% include-markdown "./presume_benevolence.md" start="" + end="" %} + +- :material-sail-boat: [Avoid Surprise](./avoid_surprise.md) + + --- + {% include-markdown "./avoid_surprise.md" start="" + end="" %} + +- :fontawesome-solid-ice-cream: [Incentivize Desired Behavior](./incentivize_behavior.md) + + --- + {% include-markdown "./incentivize_behavior.md" start="" + end="" %} + +- :material-ruler-square: [Ethical Considerations](./ethics.md) + + --- + {% include-markdown "./ethics.md" start="" + end="" %} + +- :octicons-graph-16: [Process Improvement](./process_improvement.md) + + --- + {% include-markdown "./process_improvement.md" start="" + end="" %} + +- :material-vector-triangle: [CVD is a Wicked Problem](./wicked_problem.md) + + --- + {% include-markdown "./wicked_problem.md" start="" + end="" %} + +
diff --git a/docs/topics/principles/presume_benevolence.md b/docs/topics/principles/presume_benevolence.md new file mode 100644 index 0000000..9150cef --- /dev/null +++ b/docs/topics/principles/presume_benevolence.md @@ -0,0 +1,47 @@ +# Presume Benevolence + +[Benevolence](https://plato.stanford.edu/entries/principle-beneficence/) refers to the morally valuable character trait or virtue of +being inclined to act to benefit others. In terms of the CVD process, we +have found that it is usually best to assume that any individual who has +taken the time and effort to reach out to a vendor or a coordinator to +report an issue is likely benevolent and sincerely wishes to reduce the +risk posed by the vulnerability. While each reporter may have secondary +motives (such as those listed in Table 1 below), and may even be +difficult to work with at times, allowing negative associations about a +CVD participants' motives to accumulate can color your language and +discussions with them. + +!!! tip "Balancing Trust and Skepticism" + + This isn't to say you should maintain your belief that researcher is + acting in good faith when presented with evidence to the contrary. + Rather, one should keep in mind that participants are working toward a + common goal: [reducing the harm](reduce_harm.md) caused by deployed insecure systems. + +!!! info "Finder/Reporter Motivations" + + [I Am the Cavalry](https://www.iamthecavalry.org/motivations/) describes Finder/Reporter motivations thus: + + | Finder / Reporter Motivation | Summary | Description | + |:----------------------------:|:------------------------------|:-----------------------------------------------------------------------------------------------| + | Protect | make the world a safer place | These researchers are drawn to problems where they feel they can make a difference. | + | Puzzle | tinker out of curiosity | This type of researcher is typically a hobbyist and is driven to understand how things work. | + | Prestige | seek pride and notability | These researchers often want to be the best, or very well known for their work. | + | Profit | to earn money | These researchers trade on their skills as a primary or secondary income. | + | Politics | ideological and principled | These researchers, whether patriots or protestors, strongly support or oppose causes. | + +!!! info "NTIA Insights" + + In 2016, the Awareness and Adoption Group within the + [NTIA Multistakeholder Process for Cybersecurity Vulnerabilities](https://www.ntia.doc.gov/other-publication/2016/multistakeholder-process-cybersecurity-vulnerabilities) + surveyed security researchers and vendors, + [finding](https://www.ntia.doc.gov/files/ntia/publications/2016_ntia_a_a_vulnerability_disclosure_insights_report.pdf) + that: + + - 92% of researchers participate in some form of CVD. + - 70% of researchers expected regular communication from the vendor + about their report. Frustrated expectations were often cited as the + reason for abandoning the CVD process + - 60% of researchers cited threat of legal action as a reason they + might not work with a vendor to disclose + - 15% of researchers expected a bounty in return for their disclosure diff --git a/docs/topics/principles/process_improvement.md b/docs/topics/principles/process_improvement.md new file mode 100644 index 0000000..eb31741 --- /dev/null +++ b/docs/topics/principles/process_improvement.md @@ -0,0 +1,99 @@ +# Process Improvement + +In reviewing their experience in the CVD process, participants should +capture ideas that worked well and note failures. This feedback can be +used to improve both the Software Development Lifecycle and the CVD +process itself. + +The CVD process can create a pipeline for regular patching cycles and +may reveal blocking issues that prevent a more efficient software patch +deployment mechanism. A successful program provides the vendor with a +degree of crowdsourcing for security research and testing of its +products. However, CVD should be considered complementary to a vendor's +internal research and testing as part of the Software Development +Lifecycle, not as a wholesale replacement for internally driven security +testing. + +## CVD and the Security Feedback Loop + +!!! example inline end "Milk or Wine" + + Andy Ozment and Stuart Schechter studied the impact of legacy code on the security + of modern software and how large code changes might introduce + vulnerabilities in their 2006 paper + [*Milk or Wine: Does Software Security Improve with Age?*](https://www.usenix.org/legacy/event/sec06/tech/full_papers/ozment/ozment.pdf) + + They found that over a 7.5 year span, nearly two-thirds of the lines of code in then-current versions + of OpenBSD had not been altered during the study period. Furthermore, a similar fraction of reported vulnerabilities + were present when the study began, representing accumulated security debt. + The rate at which these foundational vulnerabilities were being reported was decreasing, but the decrease was not rapid. + The median lifetime of foundational vulnerabilities was at least two and a half years. + +A successful CVD program feeds vulnerability information back into the +vendor's Software Development Lifecycle. This information can result in +more secure development processes, helping to prevent the introduction +of vulnerabilities in the first place. + +Yet the reality of today's software is that much of its legacy code was +not originally produced within a secure development process. +The positive news is that *foundational +vulnerabilities*—ones that existed in the very first release and +carried through the most recent version of the software—decay over +time. We can find them, fix them, and make the code base stronger +overall. However, the bad news is that as the low-hanging fruit of +foundational vulnerabilities are fixed, the remaining foundational +vulnerabilities tend to be more subtle or complex, making them +increasingly difficult to discover. + +Furthermore, ongoing development and code changes can introduce new +vulnerabilities, making it unlikely for the security process to ever be +"finished." Even with modern architecture development and secure +coding practices, software bugs (and in particular security +vulnerabilities) remain a likely result as new features are added or +code is refactored. This can happen for many reasons, not all of them +technical. + +!!! example inline end "Bad Software Architecture is a People Problem" + + Kate Matsudaira's article in [ACM Queue](https://queue.acm.org/detail.cfm?id=2974011) + highlights the difficulty of getting teams + of people to work together, resulting in poor software architecture. + While primarily concerned with maintainability + and performance, bugs (including security vulnerability bugs) are + an important side effect of inadequate architecture and teamwork + process. + +Another possibility is that, even with good internal processes and +teamwork, [no software model or specification can comprehensively account +for the variety of environments the software may operate in](https://www.computer.org/csdl/proceedings-article/csda/1998/03370026/12OmNrMHOcu). If we +cannot predict the environment, we cannot predict all the ways that +things may go wrong. In fact, [research](https://www.microsoft.com/en-us/research/blog/12-18-14-equation-of-a-fuzzing-curve-part-1-2/) has shown that it appears +[impossible](https://www.microsoft.com/en-us/research/blog/equation-of-a-fuzzing-curve-part-2-2/) to model or predict the number of vulnerabilities that may be +found through tools like fuzzing—and, by extension, [the number of +vulnerabilities that exist in a product](https://insights.sei.cmu.edu/library/an-analysis-of-how-many-undiscovered-vulnerabilities-remain-in-information-systems/). + +A successful CVD process helps encourage the search for and reporting of +vulnerabilities while minimizing harm to users. Developers supporting a +successful CVD process can expect to see the overall security of their +code improve over time as vulnerabilities are found and removed. + +!!! tip "Expect Vulnerabilities to Persist" + + The best advice seems + to be to assume that vulnerabilities will be found indefinitely into the + future and work to ensure that any remaining vulnerabilities cause + minimal harm to users and systems. + +## Improving the CVD Process Itself + +Feeding lessons learned back into the development process, CVD can: + +- reduce creation of new vulnerabilities +- increase pre-release testing to find vulnerabilities + +Participation in CVD may allow discussions between your developers and +security researchers on new tools or methods for vulnerability discovery +such as static analysis or fuzzing. These tools and methods can then be +evaluated for inclusion in ongoing development processes if they succeed +in finding bugs and vulnerabilities in your product. Essentially, CVD +can facilitate field testing of new analysis methods for finding bugs. diff --git a/docs/topics/principles/reduce_harm.md b/docs/topics/principles/reduce_harm.md new file mode 100644 index 0000000..edd8204 --- /dev/null +++ b/docs/topics/principles/reduce_harm.md @@ -0,0 +1,82 @@ +# Reduce Harm + +Harm reduction is a term borrowed from the public health community. In +that context, it is used to describe efforts intended to reduce the harm +caused by drug use and unsafe health practices, rather than on the +eradication of the problem. + +!!! info "Harm Reduction in Public Health" + + One of the tenets of harm reduction is that there will never be a drug-free society, + and so preparations must be made to reduce the harm of drugs that currently + exist since we will never be completely free of them. This + concept applies to software vulnerabilities as well: that it may be + possible to reduce the potential for harm even if vulnerabilities cannot + be fully eliminated. + + For more on Harm Reduction in the public health context, see + + - [National Harm Reduction Coalition](http://harmreduction.org/about-us/principles-of-harm-reduction/) + - [Harm Reduction International](https://www.hri.global/what-is-harm-reduction) + +At its core, harm reduction with respect to vulnerable software is about +balancing the ability for system defenders to take action while avoiding +an increase in attacker advantage. Experience has shown that nearly all +software-centric products contain vulnerabilities, and this will likely +remain true, especially as code complexity continues to increase. + +```mermaid +flowchart LR + subgraph A[Harm Reduction] + direction LR + action[Enable Defenders
to Take Action] + avoid[Avoid Increasing
Attacker Advantage] + end + action <-->|balance| avoid +``` + +In fact, the potential for vulnerabilities will likely never go away +since a previously secure system can become vulnerable when deployed +into a new context, or simply due to environmental changes or the +development of novel attack techniques. Systems tend to outlive their +threat models. + +!!! example "The Flatiron Building in New York City" + + The Flatiron Building in New York City stands as an + example of this phenomenon in the physical world. Built prior to the + Wright brothers' flight at Kitty Hawk, NC, today it is vulnerable to + attack using an airliner as a weapon. It's difficult to argue that the + designers should have "built security in" for attacks that would have + been considered [science fiction](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=442528) at the time of deployment. + +Since vulnerabilities are likely to persist despite our best efforts, +CVD works best when it focuses on reducing the harm vulnerabilities can +cause. + +!!! tip "Approaches to Reduce Harm in CVD" + + Some approaches to reducing the harm caused by vulnerable + software and systems include the following: + + - **Publish vulnerability information**. Providing high-quality, + timely, targeted, automated dissemination of vulnerability + information enables defenders to make informed decisions and take + action quickly. + + - **Encourage the adoption and widespread use of exploit mitigation + techniques** on all platforms. + + - **Reduce days of risk**. [Selecting reasonable disclosure deadlines](https://link.springer.com/article/10.1007/s10796-006-9012-5) is + one way of achieving the goal of minimizing the time between a + vulnerability's discovery and the remediation of its last deployed + instance. + + - **Release high-quality patches**. Increasing defenders' trust that + patches won't break things or have undesirable side effects reduces + lag in patch deployment by reducing the defenders' testing burden. + + - **Automate patch deployment** Automation coupled with a high degree of deployer trust in patch quality + can improve patch deployment rates. To avoid automated deployment mechanisms becoming a new + target for adversaries, vendors should use secure update mechanisms including + cryptographically signed updates or other technologies. diff --git a/docs/topics/principles/wicked_problem.md b/docs/topics/principles/wicked_problem.md new file mode 100644 index 0000000..58d479e --- /dev/null +++ b/docs/topics/principles/wicked_problem.md @@ -0,0 +1,39 @@ +# CVD is a Wicked Problem + +!!! question "What is a Wicked Problem?" + + The term *wicked problem* was first introduced by Horst Rittel and + Melvin Webber in 1973. The term was used to describe a class of + social system problems that are ill-formulated, where the information + is confusing, where there are many clients and decision makers with + conflicting values, and where the ramifications in the whole system + are thoroughly confusing. The term *wicked* is used, not in the sense + of evil, but rather in the sense that these problems are tricky and + difficult. The term *wicked problem* is used to describe a problem that + is difficult or impossible to solve because of incomplete, contradictory, + and changing requirements that are often difficult to recognize. + + For a broader discussion of wicked problems, see the Wikipedia + article on [Wicked Problems](https://en.wikipedia.org/wiki/Wicked_problem). + + H. W. Rittel and M. M. Webber, "Dilemmas in a General Theory of + Planning," *Policy Sciences,* vol. 4, no. 1973, pp. 155-169, June + 1973. + +Because of the complexity of coordinating vulnerability disclosure, we consider it a wicked problem. +The following table lists the characteristics of wicked problems. +Anyone familiar with the CVD process will likely recognize these characteristics +in both the individual cases and the overarching process itself. + +| Characteristics of Wicked Problems | Description | +|------------------------------------|-------------| +| 1. No definitive formulation | solving the problem is analogous to understanding it. | +| 2. No stopping rule | the problem has no intrinsic criteria to indicate that a solution is sufficient; solutions depend rather on the planner deciding to stop planning. | +| 3. Not true-or-false, but good-or-bad | the judgement of a solution's fitness by parties involved will be filtered through their values and their predisposed ideology. | +| 4. No immediate and no ultimate test | solutions can have far-reaching and not always clear effects in both time and scope. | +| 5. One-shot operation | actions taken in response to the problem affect the options available to future solutions. | +| 6. No enumerable set of potential solutions | it is not possible to demonstrate that all possible solutions have been considered or even identified. | +| 7. Essentially unique | despite long lists of similarities between a current problem and a previous one, there always might be an additional distinguishing property that is of overriding importance. | +| 8. A symptom of another problem | every identified cause leads to a "higher level" problem of which the current problem is a symptom. | +| 9. The choice of explanation determines the nature of the problem's resolution | The way a problem is described influences the solutions proposed. | +| 10. The planner has no right to be wrong | The goal of a solution is not to find an ultimate truth about the world, rather it is to improve conditions for those who inhabit it. | diff --git a/docs/topics/roles/coordinator.md b/docs/topics/roles/coordinator.md new file mode 100644 index 0000000..e44ae7e --- /dev/null +++ b/docs/topics/roles/coordinator.md @@ -0,0 +1,164 @@ +# Coordinator + +Complicated or complex CVD cases can often benefit from the help of a +coordinator. A coordinator acts as a relay or information broker between +other stakeholders. Several types of coordinators with slightly +different roles and domains exist. We list a few here. + +## Computer Security Incident Response Team (CSIRT) + +A Computer Security Incident Response Team (CSIRT) is a service +organization that is responsible for receiving, reviewing, and +responding to computer security incident reports and activity. Their +services are usually performed for a defined constituency that could be +a parent entity such as a corporate, governmental, or educational +organization; a region or country; a research network; or a paid client. +A CSIRT can be a formalized team or an ad-hoc team. A formalized team +performs incident response work as its major job function. An ad-hoc +team is called together during an ongoing computer security incident or +to respond to an incident when the need arises. + +!!! info "CSIRT Resources" + + The Forum of Incident Response and Security Teams (FIRST) created the + [CSIRT Services Framework](https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1). + It covers the services that a CSIRT might provide, organized into five service areas: + Information Security Event Management, Information Security Incident Management, + Vulnerability Management, Situational Awareness, and Knowledge Transfer. + + Additionally, the CERT Division of the Software Engineering Institute at Carnegie + Mellon University has created a collection of + [CSIRT Resources](https://insights.sei.cmu.edu/library/resources-for-creating-a-csirt/). + +### CSIRT with National Responsibility + +!!! example inline end "National CSIRTs" + + Just a few examples of National CSIRTs include: + + - [CISA](https://www.cisa.gov) + - [National Cyber Security Centre](https://www.ncsc.gov.uk) + - [JPCERT/CC](https://www.jpcert.or.jp/english/) + - [NCSC-NL](https://www.ncsc.nl) + +CSIRTs with National Responsibility, also known as, National CSIRTs, +are designated by a country or economy to have specific responsibilities +in cyber protection for the country or economy. A National CSIRT can be +inside or outside of government, but must be specifically recognized by +the government as having responsibility in the country or economy. +In addition to functioning as a clearing house for incident response +across government departments and agencies, CSIRTs with National +Responsibility often have some degree of responsibility or oversight for +coordinating vulnerability response across their nation's critical +infrastructure. + +!!! info "National CSIRT Resources" + + The CERT Division has compiled a collection of [National CSIRT Resources](https://insights.sei.cmu.edu/library/natcsirt-resources/). + +### Product Security Incident Response Team (PSIRT) + +{% include-markdown "../../_includes/_psirt_example.md" %} + +Product Security Incident Response Teams (PSIRTs) have +emerged as a specialized form of CSIRT, allowing vendors to focus their +response to product security issues. Although not all vendors have +dedicated PSIRTs, vulnerability response is sufficiently different from +security incident response that larger vendor organizations can usually +justify having a distinct function to deal with it. PSIRTs usually +provide an interface to the outside world to receive vulnerability +reports as well as serving as a central coordinator between internal +departments for the organization's vulnerability response for its +products. When reporting a vulnerability to a vendor, the reporter will +usually be communicating with the vendor's PSIRT. + +{% include-markdown "../../_includes/_first_psirt.md" %} + +## Security Research Organizations + +!!! example inline end "Security Research Organizations" + + Some examples of organizations that might coordinate vulnerabilities they find include + + - managed security service providers + - government agencies + - academic research teams + + Additionally, vendors of products or services sometimes combine their PSIRT’s vulnerability response + capability with their externally facing coordination capability. + +Organizations that perform security research on other vendors’ products in the course of their +own business sometimes establish their own coordination capability in order to handle the +disclosure process for the vulnerabilities they find. A wide variety of organizations perform this +kind of security research, whether for profit or for non-commercial reasons. + +Furthermore, organizations that provide vulnerability management and scanning tools and +services are often well-positioned to act as a disclosure coordinator for the vulnerabilities their +products detect. This applies especially when those vulnerabilities have not already been +disclosed to either the vendor or the public. Alternatively, organizations such as these may +choose to partner with another coordinating organization in order to promote transparency +and reduce the perception of bias in their vulnerability disclosure process. + +## Bug Bounty Programs + +Many individual vendors have established bug bounty programs to compensate security +researchers for their efforts in discovering vulnerabilities in the vendor’s products. Creation of +a bug bounty program has been noted as an indicator of maturity in vendors’ vulnerability +response efforts. + +!!! warning "Bug Bounty Programs and Vulnerability Coordination" + + Bug bounty programs by themselves are not the same as a vulnerability coordination capability. + Bug bounty programs are a way to incentivize security researchers to report vulnerabilities to the vendor. + Importantly, they do not inherently create the internal plumbing necessary to respond to those vulnerabilities. + In some cases, vendor bug bounty programs are enabled by other companies that provide tools and services + to facilitate vulnerability coordination. + +## Vulnerability Disclosure Platforms and Commercial Brokers + +!!! example inline end "Commercial Vulnerability Disclosure Platforms" + - [BugCrowd](https://www.bugcrowd.com) + - [HackerOne](https://www.hackerone.com) + - [SynAck](https://www.synack.com) + - [Cobalt Labs Inc.](https://cobalt.io/) + +Not all vulnerability reporting programs include bug bounties. +In recent years, a new class of coordinator has emerged in the form of commercial vulnerability disclosure +platform providers. + +Companies such as those at right offer turnkey solutions for +vendors who want to bootstrap their own vulnerability response program. + +## Information Sharing and Analysis Organizations (ISAOs) and Centers (ISACs) + +!!! example inline end "ISACs" + + The [National Council of ISACs](https://www.nationalisacs.org/member-isacs-3) lists + over two dozen ISACs in the United States, each focused on a different sector of critical infrastructure. + +[Information Sharing and Analysis Organizations](https://www.isao.org/) (ISAOs) and +[Information Sharing and Analysis Centers](https://www.nationalisacs.org/) +(ISACs) are non-government entities that serve various roles in +gathering, analyzing, and disseminating critical infrastructure +cybersecurity information across private sector organizations of various +sizes and capabilities. These organizations are increasingly involved +in the coordination and deployment of vulnerability mitigations. +Furthermore, we have observed a growing interest from critical +infrastructure sectors engaging with the +coordination of the vulnerability discovery, disclosure, and remediation +processes. + +## Traditional Coordinators + +!!! example inline end "Third-Party Coordinators" + - [CERT/CC](https://www.kb.cert.org) + - [JPCERT/CC](https://www.jpcert.or.jp/english/) + - [NCSC-NL](https://www.ncsc.nl) + - [NCSC-FI](https://www.kyberturvallisuuskeskus.fi/en/) + +While most CVD programs help address the CVD needs of individual vendors, there still are +vulnerabilities that require larger scale coordination. In particular, Multi-Party Coordinated +Vulnerability Disclosure (MPCVD) remains a challenge for many organizations. +As individual +vendors have become more mature in their handling of vulnerabilities in their products, the +role of MPCVD has increased in importance for more traditional vulnerability coordinators. diff --git a/docs/topics/roles/deployer.md b/docs/topics/roles/deployer.md new file mode 100644 index 0000000..b4f7ae3 --- /dev/null +++ b/docs/topics/roles/deployer.md @@ -0,0 +1,30 @@ +# Deployer + +The *deployer* role refers to the individual or organization responsible +for the fielded systems that use or otherwise depend on products with +vulnerabilities. + +Deployers include the following: + +- network and cloud infrastructure providers +- outsourced IT operations +- in-house IT operations +- individual users + +Deployers typically must take some action in response to a vulnerability +in a product they've deployed. Most often this means deploying a patch, +but it can also involve the application of security controls, such as +reconfiguring defensive systems, adding monitoring or detection rules, +or applying mitigations. + +Automation of the deployment process increases the efficiency of the +deployer's response at the same time it decreases the duration of the +risk posed by vulnerable systems. +Although the deployer role is primarily concerned with Vulnerability +Management practices that sit downstream of CVD, it's worth spending a +few moments to understand how it fits in with CVD. + +!!! tip "Deployer Vulnerability Response Process" + + We describe the deployer's vulnerability response process in more + detail in the section [Deployer Vulnerability Response](../../tutorials/response_process/deployer.md). diff --git a/docs/topics/roles/finder.md b/docs/topics/roles/finder.md new file mode 100644 index 0000000..92a093e --- /dev/null +++ b/docs/topics/roles/finder.md @@ -0,0 +1,136 @@ +# Finder + +!!! quote "ISO/IEC 29147:2014" + + Finder: individual or organization that identifies a potential + vulnerability in a product or online service. Note that finders can be researchers, security companies, users, + governments, or coordinators. + +In the interest of consistency, we will use this +definition of finder, although in other documentation we've used the +term *discoverer* for this same role. We do, however, distinguish between +the role of *finder* and the role of *reporter*, as seen in this section and +the next. + +We sometimes use *finder/reporter* to refer to the person or organization +that both finds and reports a vulnerability. + +## Who Finds Vulnerabilities? + +Vulnerabilities can be found by just about anyone. All it takes is for +someone to notice an unexpected or surprising behavior of a system. +Although it is common for independent security researchers to hunt +vulnerabilities as either a hobby or profession, finders need not +self-identify as security researchers or hackers. + +!!! example "Vulnerabilities have been found by people of many backgrounds" + + - students and professional academics studying novel ways to exploit + systems or protocols + - open source developers who notice that a software bug has security + implications + - system administrators who recognize a vulnerability during the + course of troubleshooting a system error + - professional security analysts who observe a previously unknown + product vulnerability while testing an organization's + infrastructure during a penetration test engagement + - people using software or web services who mistyped some input or + simply clicked on the wrong thing + - children who like to press buttons. A [BBC article](http://www.bbc.com/news/technology-26879185) + describes how a 5-year old found a vulnerability in + Microsoft's Xbox Live service just by holding down the space bar + and was able to log in to his father's account without the password. + +There are also organizations that look for vulnerabilities. Some of them +work under contract to vendors directly. Some work for the vendors' +customers who deploy the software. And some have independent motivation +to find vulnerabilities, perhaps to demonstrate their competence in +finding vulnerabilities in the interest of their security consulting +practice's business development. + +Furthermore, vendors may choose to look for vulnerabilities in their own +products—a practice that we strongly encourage. This can be done via + +- in-house expertise and testing +- contracted security testing +- solicited on a per-vulnerability basis using a bug bounty program + +!!! example "Vendors Integrate Testing for Vulnerabilities into Development" + + Many vendors integrate testing for vulnerabilities into their development process. + Microsoft, for example, includes static, dynamic, + and fuzz testing for vulnerabilities in its phases of the [Security + Development Lifecycle](https://www.microsoft.com/en-us/sdl/). + The [Building Security In Maturity Model](https://www.bsimm.com/framework/) (BSIMM) + suggests that many vendors in various industries already employ techniques in architecture + analysis, code review, and security testing to find vulnerabilities as + part of their development cycle. + +### What Happens After a Vulnerability is Found? + +!!! example inline end "First Steps After Finding a Vulnerability" + + The following flowchart illustrates the process of finding a + vulnerability and the subsequent steps that might be taken. + + ```mermaid + flowchart TD + start([Vulnerability Found]) + compose_report[1. Compose a vulnerability report] + provide_report[2. Provide the report to someone] + prepare_document[3. Prepare & Publish] + start --> compose_report + compose_report --> provide_report + provide_report -.->|optional| prepare_document + + ``` + +Regardless of who finds a vulnerability, there are a few common events +that follow the discovery: + +1. The finder composes a vulnerability report, as discussed in [Reporting](../phases/reporting.md) +2. The finder (or reporter, if these are distinct individuals) provides + that report to someone. Often the vulnerability report would be + provided to the [vendor](vendor.md), but that's not always the case. Sometimes + the report might be sent to a [coordinator](coordinator.md). If the vulnerability is + discovered internally to a vendor, then the report may simply be + forwarded to the responsible team within the organization—for + example, filed as a security-related bug report. +3. (Optional) Finders, reporters, vendors, or coordinators might + [prepare a document to publish](../phases/public_awareness.md). The finder often wants to draw + attention to his or her discovery and subsequent analysis by + publishing a document, blog post, or conference presentation, to + share the findings with a larger audience. Vendors typically want to + publish a document as well to inform their users that action has + been taken to resolve the problem, and to prompt their users to take + any required remediation actions. + +!!! tip "Regarding Non-Disclosure" + + It is of course [possible](../../howto/preparation/disclosure_choices.md) for a finder to find a vulnerability and tell + no one. However, in that case there is no disclosure involved so we do + not address that scenario further in this documentation. + +## Reporter + +The defining characteristic of vulnerability *reporters* is that they +originate the message that informs a vendor or coordinator of a +vulnerability. + +!!! example "When the finder is not the reporter" + + In most cases, the *reporter* is also the [*finder*](finder.md) of the + vulnerability. However, this is not always the case. For example, the + finder might be an employee at an organization that also has in-house + vulnerability coordinators who act as the communications liaison with + the affected vendor(s). + + Alternatively, it could be that someone analyzing a piece of malware + realized that it exploited a previously undisclosed vulnerability. In + both cases, the party communicating the vulnerability information to the + vendor is not the original finder. + +That said, whether or not the +*reporter* is the original *finder* is often not as relevant as whether the +newly provided information is sufficient to determine the existence and +impact of the problem reported. diff --git a/docs/topics/roles/index.md b/docs/topics/roles/index.md new file mode 100644 index 0000000..4971979 --- /dev/null +++ b/docs/topics/roles/index.md @@ -0,0 +1,58 @@ +# Roles in Coordinated Vulnerability Disclosure + +Certain roles are critical to the Coordinated Vulnerability Disclosure +process, as described in the following sections: + +
+ +- :material-magnify: [**Finder (Discoverer)**](finder.md) -- the individual or organization that identifies the vulnerability +- :material-message-alert: [**Reporter**](finder.md) -- the individual or organization that notifies the vendor of the vulnerability +- :material-code-braces: [**Vendor**](vendor.md) -- the individual or organization that created or maintains the product that is vulnerable +- :material-server: [**Deployer**](deployer.md) -- the individual or organization that must deploy a patch or take other remediation action +- :material-arrow-decision: [**Coordinator**](coordinator.md) -- an individual or organization that facilitates the coordinated response process +- :octicons-people-16: [**Other Roles**](other_roles.md) -- other roles that may be involved in the CVD process + +
+ +!!! tip "Participants Can Play Multiple Roles" + + It is possible and often the case that individuals and organizations + play multiple roles. For example, a cloud service provider might act as + both vendor and deployer, while a researcher might act as both finder + and reporter. A vendor may also be both a deployer and a coordinator. In + fact, the CERT/CC has played all five roles over time, although not + usually simultaneously. + +## Relationships Between Roles + +Although a more detailed description of the CVD process is provided in [Phases of CVD](../phases/index.md), a simple sketch of the relationships +between these roles is shown in the figure below. + +```mermaid +--- +title: Coordination Relationships in CVD +--- +flowchart TB + subgraph C[Coordination] + direction LR + subgraph A[Often
Same
Entity] + reporter([Reporter]) + finder([Finder]) + end + vendor([Vendor]) + subgraph D[Sometimes
Included] + coordinator([Coordinator]) + deployer([Deployer]) + end + end + public([Public]) + + finder <--> reporter + reporter <--> vendor + vendor <-.-> coordinator + reporter <-.-> coordinator + vendor <-.-> deployer + coordinator <-.-> deployer + reporter <-.-> deployer + C -->|publish| public +``` diff --git a/docs/topics/roles/other_roles.md b/docs/topics/roles/other_roles.md new file mode 100644 index 0000000..a4837aa --- /dev/null +++ b/docs/topics/roles/other_roles.md @@ -0,0 +1,192 @@ +# Other Roles and Variations + +There can be other roles in the CVD process too, but they tend to be +subordinate to the ones already described. We discuss a few of them +here. + +## Users + +Individual users of vulnerable products overlap with [deployers](deployer.md). +In the case where the user must trigger an update or +install a patch, the user is playing the role of a deployer. In other +cases, the user depends on another deployer (e.g., the user's IT +support staff or an app store's automatic update capability). In these +latter cases the user does not play as active a role in the +vulnerability response process. + +## Integrator + +System integrators most often can be considered as playing the [deployer](deployer.md) +role; however, depending on their contractual responsibilities and +business relationships, they may also play roles as [vendors](vendor.md) or even +[coordinators](coordinator.md) in some cases. + +## Cloud and Application Service Providers + +Insofar as cloud-based services are built on traditional computing +platforms, cloud service providers can be considered both +[vendors](vendor.md) and [deployers](deployer.md). +However, as cloud-based services (e.g., software, +platform, and infrastructure as a service) have risen to prominence, +they have also distinguished themselves from traditional software +vendors in that their development, deployment, and delivery processes +for security fixes tend to be much more direct. + +!!! question "How is cloud different?" + + For many cloud providers, the number of distinct instances of their + software is quite limited, and control is centralized, so there are + fewer independent decision makers in the path from vulnerability report + to patch deployment. + + Furthermore, the prevalence of DevOps practices among such providers + means that the time from code commit to last vulnerable system patched + can sometimes be measured in minutes. To be sure, development and + delivery processes in traditional software environments have accelerated + considerably as well, but the fact that cloud service providers have + direct control over the vulnerable systems makes a significant + difference in their ability to mitigate vulnerabilities across all their + users in short order. + +## Internet of Things + +Another class of vendors are those of Internet of Things (IoT) +products. The physicality of IoT products and services often places them +on the opposite end of the deployment spectrum from cloud-based +services. + +IoT supply chains tend to be longer or more complex than traditional software +and sometimes cloud-based services. +In some cases, the vendor of an IoT product has very little to do with the hardware, +firmware, or software development of the product it sells. We frequently +observe pervasive use of third-party libraries in integrated products +with neither recognition of nor adequate planning for how to fix or +mitigate the vulnerabilities they inevitably contain. + +!!! question "How is IoT different?" + + Unlike most other devices (laptops, PCs, smartphones, tablets), many of + today's IoT products are either non-updatable or require significant + effort to update. Whether we're talking about cars, televisions, + medical devices, airplanes, sensors, home automation, or industrial + control systems, too often today the patch deployment process involves + going out and physically touching the thing that must be updated. + Systems that cannot be updated become less secure over time as new + vulnerabilities are found and novel attack techniques emerge. Because + vulnerabilities are often discovered long after a system has been + delivered, systems that lack facilities for secure updates once deployed + present a long-term risk to the networks in which they reside. This + design flaw is perhaps the most significant one already found in many + IoT products, and if not corrected across the board, could lead to years + if not decades of increasingly insecure devices acting as reservoirs of + infection or as platforms for lateral movement by adversaries of all + types. Patch deployment will likely improve as more connected things get + over-the-air (OTA) update capabilities, but there is already a large + installed base of systems lacking such features. + + Furthermore, systems at the lower end of the price range might have + "fire and forget" assumptions built into their pricing model, meaning + that there is neither the technical means to deliver updates nor the + support capability in place to even develop them in the first place. In + the long run, regulatory intervention seems poised to influence IoT vendors to + improve their vulnerability response capabilities, but the gap today is + large and will likely be difficult to close entirely unless market + incentives shift toward more holistic and improved security posture. + + We have more to say about [IoT and CVD](../special/iot_cvd.md) in our Special Topics section. + +!!! warning "Dependencies and *black box* code" + + When developers + embed a library into their product, that product often inherits + vulnerabilities subsequently found in the incorporated code. Although + the third-party library problem is equally pervasive in the traditional + computing, cloud, and mobile worlds, it is even more concerning in + contexts where many libraries wind up as binary blobs and are simply + included in the firmware as such. Lacking the ability to analyze this + black box code either in manual source code reviews or using most code + analysis tools, IoT vendors may find it difficult to examine and improve + the code's security. + +## Mobile Platforms and Applications + +Mobile devices present yet another class of stakeholders that has grown +distinct in recent years. The device vendors themselves are most akin to +IoT vendors, but app developers can be quite a diverse bunch, ranging +from very large traditional software companies, to cloud service +providers, to novices with a good idea and a few hours of coding. +Perhaps the most significant outstanding issue is that many mobile +devices have multi-stage, vertical supply chains, each step of which can +stand in the way of security updates reaching their intended +beneficiaries (i.e., the users). In both the mobile and IoT +spaces, high-viscosity supply chains are bad for end-user +security. + +{% include-markdown "../../_includes/_mobile_supply_chain.md" heading-offset=1 %} + +## Governments + +Governments are multifaceted stakeholders in regards to cybersecurity +vulnerabilities and their disclosure. While they have always had a role +as owners and operators of vulnerable networks and systems, issues +surrounding vulnerability discovery, coordination, disclosure, and +mitigation have become increasingly important to governments worldwide. + +
+ +!!! tip "Regulatory Oversight" + + As the industries they regulate move toward increasing connectivity, + agencies with oversight responsibilities will likely see an increased + demand to extend their safety monitoring to include security issues + (especially for security issues that directly impact safety). To that + end, changes are happening rapidly on multiple fronts. + +!!! example "Reporting Safety Issues" + + In the United States, a number of mechanisms exist for reporting safety + issues to government agencies. Software vulnerabilities that impact + safety are increasingly being reported through these channels. + + - The [FDA Medical Device Reporting process](https://www.fda.gov/medicaldevices/safety/reportaproblem/) + enables oversight and detection of + potential device-related safety issues. + - The National Highway Transportation and Safety Commission (NHTSA) collects + [reports of vehicle safety issues](https://www.nhtsa.gov/report-a-safety-problem), + which helps to drive its investigation and recall processes. + - The FAA offers a number of [safety reporting](https://www.faa.gov/aircraft/safety/report/) capabilities as well. + +!!! tip "Continuous Improvement" + + Beyond just documenting observed issues, some government agencies take + an active learning approach when broader engineering failures occur. The + aforementioned FDA and NHTSA reporting programs serve this purpose, but + other programs exist as well. + +!!! example "Lessons Learned" + + For example, the National Transportation Safety Board is explicitly tasked with investigating transportation + accidents, and NASA collects [lessons learned](https://llis.nasa.gov/) in a public database. + This kind of continuous improvement process has demonstrated its effectiveness in a variety of environments and + seems to provide a good model for cybersecurity vulnerabilities in both the private and public sectors. + +
+ +!!! example "International Developments" + + The United States is not alone in realizing that vulnerability + discovery, disclosure, and remediation is important to national + interests. These cybersecurity issues have been global for quite some + time. + + - In 2022, [ENISA](https://www.enisa.europa.eu/), the [European Union Agency for Cybersecurity](https://www.enisa.europa.eu/), published + a report on [Coordinated Vulnerability Disclosure Policies in the EU](https://www.enisa.europa.eu/publications/coordinated-vulnerability-disclosure-policies-in-the-eu) + + - The European Commission has proposed a [Cyber Resilience Act](https://www.european-cyber-resilience-act.com/) + to address two major problems: + + > 1. The low level of cybersecurity of products with digital elements, reflected by widespread vulnerabilities and the insufficient and inconsistent provision of security updates to address them. + > 2. The insufficient understanding and access to information by users, preventing them from choosing products with adequate cybersecurity properties or using them in a secure manner. + + The act was approved by EU Parliament in [March 2024](https://www.europarl.europa.eu/doceo/document/TA-9-2024-0130_EN.html), + clearing the way for adoption by the Council of the European Union. diff --git a/docs/topics/roles/vendor.md b/docs/topics/roles/vendor.md new file mode 100644 index 0000000..aa3f2c7 --- /dev/null +++ b/docs/topics/roles/vendor.md @@ -0,0 +1,201 @@ +# Vendor + +!!! info inline end "Synonyms for *Vendor*" + + Other terms used to represent the concept of _vendor_ include: + supplier, manufacturer, producer, creator, developer, author, + maintainer, provider, publisher, and distributor. + +The *vendor* is the party responsible for updating the product +containing the vulnerability. Most often a vendor is a company or other +organization, but an individual can also be a vendor. For example, a +student who developed an app and placed it in a mobile app store for +free download meets this definition of vendor, as does a large +multinational company with thousands of developers across the globe. +Many open source libraries are maintained by a single person or a small +independent team; we still refer to these individuals and groups as +vendors. + + +
+ +{% include-markdown "../../_includes/_who_is_a_vendor.md" heading-indent=1 %} + +!!! example "Vendor Perspectives" + + The [NTIA Awareness and Adoption Working Group survey](https://www.ntia.doc.gov/files/ntia/publications/2016_ntia_a_a_vulnerability_disclosure_insights_report.pdf) + found the following: + + - 60-80% of the more mature vendors followed CVD practices + - 76% of those mature vendors developed their vulnerability handling + procedures in-house. + - Vendors' perceived need for a vulnerability disclosure policy was + driven by a sense of corporate responsibility or customer demand. + - Only a third of responding companies considered and/or required + suppliers to have their own vulnerability handling procedures. + +!!! warning "Vendor as the Introducer of Vulnerabilities" + + The vendor often plays an important but less discussed role as well, as + the creator of the software or system that introduces the vulnerability. + This is a different perspective on the concept of the _originating vendor_ in the next section. + + While good practices like code reviews, continuous testing and + integration, well-trained developers, mentoring, architectural choices, + and so forth can reduce the rate of introduction of new vulnerabilities, + these practices thus far have not eliminated them completely. Thus, a + well-established CVD capability is also essential to the development + process. + +## Vendors as Part of the Software Supply Chain + +Although a single vendor is usually the originator of a patch for a +given vulnerability (also known as the *originating vendor*), this is not always the case. +Some vendors will have products affected by a vulnerability while they are not the originator +of the initial fix. +We refer to these vendors as *downstream vendors*, as they are downstream in the software supply chain +from the *originating vendor*. +By contrast then, an *upstream vendor* is a vendor that provides a component to another vendor. +Furthermore, since many modern products are in fact composed of +software and hardware components from multiple vendors, the CVD process +increasingly involves multiple tiers of vendors, as we discuss in +[Multiparty CVD](../../howto/coordination/mpcvd.md). +Ideally the CVD process should cover not just the +patch originator but also the downstream vendors. The complexity of the +software supply chain can make this difficult to coordinate. + +!!! abstract "Originating Vendor" + + The _originating vendor_ is the vendor of a product in which a vulnerability is located. + The _originating vendor_ is responsible for creating the patch to fix the vulnerability. + +!!! abstract "Downstream Vendor" + + A _downstream vendor_ is a vendor that uses a component from another vendor in their own product. + If the component contains a vulnerability, the _downstream vendor_ is responsible for updating their product to include the patch + provided by the _originating vendor_. + +!!! abstract "Upstream Vendor" + + An _upstream vendor_ is a vendor that provides a component to another vendor. + If the component contains a vulnerability, the _upstream vendor_ is responsible for providing a patch to the _downstream vendor_. + The _originating vendor_ is also an _upstream vendor_ in the context of the _downstream vendor_. + But there may be multiple _upstream vendors_ in the software supply chain. + +!!! example "Originating, Upstream, and Downstream Roles are Relative to the Software Supply Chain" + + The roles of _originating vendor_, _downstream vendor_, and _upstream vendor_ are relative to the software supply chain. + The diagram below illustrates the relationships between these roles. + + ```mermaid + --- + title: Vendor Roles + --- + flowchart LR + V0[Vendor 0] + V1[Vendor 1] + V2[Vendor 2] + V0 -->|provides
fix| V1 + V1 -->|provides
fix| V2 + ``` + + Vendor 0 is the _originating vendor_ of the patch, and is an _upstream vendor_ to Vendor 1. + Vendor 1 and Vendor 2 are _downstream vendors_ to Vendor 0, although + it is possible that Vendor 0 might not even be aware of Vendor 2. + Vendor 1 is also an _upstream vendor_ to Vendor 2, and Vendor 2 is a _downstream vendor_ to Vendor 1. + + | Vendor
perspective | Vendor 0
Role | Vendor 1
Role | Vendor 2
Role | + |:-----------------------:|----------------------------------------|-------------------|-------------------| + | Vendor 0 | Originating Vendor
self | Downstream Vendor | Downstream Vendor | + | Vendor 1 | Originating Vendor
Upstream Vendor | self | Downstream Vendor | + | Vendor 2 | Originating Vendor
Upstream Vendor | Upstream Vendor | self | + +!!! example "Vendor Dependencies" + + !!! example inline end "" + + ```mermaid + --- + title: Vendor Dependencies + --- + + flowchart LR + + v1[Vendor] + v2[Vendor] + v3[Vendor] + v4[Vendor] + v5[Vendor] + + v1 --> v2 + v1 --> v3 + v2 --> v4 + v3 --> v4 + v3 --> v5 + ``` + + For example, the CVD + process for a vulnerability in a software library component may need to + include the originating author of the vulnerable component as well as + all the downstream vendors who incorporated that component into their + products. Each of these vendors in turn will need to update their + products in order for the fix to be deployed to all vulnerable + systems. + +## Vendor Sub-Roles + +There are various sub-roles one might find within a vendor organization. +In small organizations, an individual might play all the sub-roles at +once. Larger organizations often have teams that correspond to the +sub-roles identified here. Each of these sub-roles has a part to play in +the vendor's vulnerability response practice. + +```mermaid +flowchart LR + subgraph "Vendor" + PSIRT + Developers + process[Process Improvement] + end +``` + +!!! tip "Product Security Incident Response Team (PSIRT)" + + {% include-markdown "../../_includes/_psirt_example.md" %} + + A vendor might choose to establish a Product Security Incident Response + Team (PSIRT). This is similar to a Computer Security Incident Response + Team (CSIRT), but is engaged for product security "incidents" (e.g., + vulnerability reports and reports of exploitation of the company's + products). The PSIRT acts as an interface between the public and the + developers. We describe PSIRTs in more detail in the [Coordinator](coordinator.md) section. + +{% include-markdown "../../_includes/_first_psirt.md" %} + +!!! tip "Developers" + + For vendors of sufficient size to have a dedicated PSIRT, the + vulnerability response and development processes are likely found in + different parts of the organization. + + The development role usually has the responsibility to: + + - identify what to fix and how to fix it + - create the patch + - integrate the patch into releasable products + + The PSIRT should be in close contact with the developers in order to + coordinated fixes. + +!!! tip "Process Improvement" + + We describe process improvement as a sub-role because it is often + necessary to improve the development process in order to prevent + vulnerabilities from being introduced in the first place. Some vendors + have a dedicated role for this, while in others it is a part-time + responsibility of the PSIRT or the developers. + +!!! tip "Vendor Response Process" + + We outline the vendor response process in more detail in + [Vendor Vulnerability Response Process](../../tutorials/response_process/vendor.md). diff --git a/docs/topics/special/challenges.md b/docs/topics/special/challenges.md new file mode 100644 index 0000000..fe01c25 --- /dev/null +++ b/docs/topics/special/challenges.md @@ -0,0 +1,299 @@ +# Common Challenges in Vulnerability Analysis and Response + +!!! info inline end "Origins of this page" + + The content on this page began as a list of challenges in vulnerability analysis and response for + IoT systems in our blog post + [_What's Different About Vulnerability Analysis and Discovery in Emerging Networked Systems?_](https://insights.sei.cmu.edu/cert/2015/01/-whats-different-about-vulnerability-analysis-and-discovery-in-emerging-networked-systems.html). + We have since recognized that many of these challenges are not unique to IoT, but are + common to many emerging networked systems, including AI/ML systems. + +In 2014-2015, the CERT/CC conducted a study of vulnerability discovery, analysis, and response for IoT systems. +At the time, we referred to these systems as "emerging networked systems" to emphasize that they were not traditional +computing systems, and the term "IoT" was not yet in common use. +From that study, we identified a number of challenges that seemed to distinguish IoT systems from traditional computing systems. +However, we have since recognized that many of these challenges are not unique to IoT, but are common to many +emerging networked systems, including AI/ML systems. Our current perspective is that these are general challenges +that can affect different types of systems in different ways. + +!!! note "About This List" + + The following list of challenges is based on our original analysis of IoT systems, but we have updated the text to + reflect the broader applicability of these challenges to other emerging networked systems. Over time, we expect to + expand this list to include additional challenges we encounter. + Each item is labeled with tags indicating which system types are most affected by the issue. + +
+ + - The tags are as follows: + + --- + - **AI/ML** : Artificial Intelligence/Machine Learning + - **IoT**: Internet of Things + - **Mobile**: Mobile applications + - **Web**: Web applications + - **Traditional**: Traditional computing systems + + - The symbols indicate the relevance of the issue to each system type: + + --- + - :material-check-all: The issue is highly relevant to the system type. + - :material-check: The issue is somewhat relevant to the system type. + - :octicons-circle-slash-16: The issue is not usually relevant to the system type. + +
+ +!!! warning "Limited Instrumentation" + + **AI/ML** :material-check-all: | + **IoT** :material-check-all: | + **Mobile** :material-check: | + **Web** :material-check-all: | + **Traditional** :octicons-circle-slash-16: + + The vulnerability analyst's ability to instrument the system in order to test its security can be limited. + + AI/ML systems can be difficult to instrument because their operation is often opaque, even to the developers who + created them. That is, while it may be possible to observe the inputs and outputs of the system, the internal + operations of the system may be difficult to observe or interpret. + Many IoT systems comprise embedded devices that are effectively black boxes at the network level. + + Web applications operated by other parties can be difficult to instrument, especially if the application is + not under the control of the analyst. This is especially true if the application is a black box, such as a SaaS + application. + + On the surface, this limitation might appear to be beneficial to the security of the system in question: + after all, if it's hard to create an analysis environment, it might be difficult to find vulnerabilities in the system. + However, the problem is that while a determined and/or well-resourced attacker can overcome such obstacles and + get on with finding vulnerabilities, a lack of instrumentation can make it difficult even for the vendor to + adequately test the security of its own products. + +!!! warning "Less Familiar System Architectures" + + **AI/ML** :material-check-all: | + **IoT** :material-check-all: | + **Mobile** :material-check: | + **Web** :octicons-circle-slash-16: | + **Traditional** :octicons-circle-slash-16: + + AI/ML systems can run on a variety of hardware architectures, including GPUs, FPGAs, and custom ASICs. + + IoT systems can run on a variety of hardware architectures, including ARM, MIPS, and others. + + Mobile systems tend to run on ARM architectures, which are increasingly common in the mobile and IoT spaces. + But a single smartphone can contain multiple system-on-a-chip processors with different architectures + (for bluetooth, wifi, gps, etc.), so the analyst may need to understand multiple architectures to fully analyze + the system. + + These architectures are often different from those most often encountered by the typical vulnerability analyst, + who is likely to be most familiar with x86 and IA64 architectures. + Although this limitation is trivially obvious at a technical level, many vulnerability researchers and analysts + will have to overcome this skill gap if they are to remain effective at finding and remediating vulnerabilities in IoT + and AI/ML systems. + +!!! warning "Limited User Interfaces" + + **AI/ML** :material-check-all: | + **IoT** :material-check-all: | + **Mobile** :octicons-circle-slash-16: | + **Web** :octicons-circle-slash-16: | + **Traditional** :octicons-circle-slash-16: + + Many AI/ML systems operate as black boxes behind an API, with no user interface at all. + + Meanwhile, the user interfaces for IoT devices are often limited, especially in comparison to traditional computing systems. + For some IoT devices, the only user interface is a smartphone app, which may not provide the level of detail needed + to perform a security analysis. + + Thus, significant effort can be required just to provide input or get the feedback needed to perform security + analysis work. + +!!! warning "Proprietary Protocols" + + **AI/ML** :material-check: | + **IoT** :material-check-all: | + **Mobile** :material-check: | + **Web** :octicons-circle-slash-16: | + **Traditional** :material-check: + + + IoT systems often use proprietary protocols, especially at the application layer. + Although the spread of HTTP/HTTPS continues in this space as it has in the traditional and mobile spaces, there are many extant protocols that are poorly documented or wholly undocumented. + + AI/ML and mobile systems may use proprietary protocols as well, but there + is often a more standardized API for interacting with the system as a whole, so this limitation is less severe in + those contexts. + + Some special-purpose traditional software also uses proprietary protocols, but the prevalence of open standards + in traditional computing systems means that this limitation is encountered less frequently in that context as well. + + Regardless, the effort required to identify and understand higher level protocols, given sometimes scant information + about them, can be daunting. + Techniques and tools for network protocol inference and reverse engineering can be effective tactics. + However, if vendors were more open with their protocol specifications, much of the need for that effort would be obviated. + +!!! warning "Lack of Updatability" + + **AI/ML** :material-check: | + **IoT** :material-check-all: | + **Mobile** :octicons-circle-slash-16: | + **Web** :octicons-circle-slash-16: | + **Traditional** :octicons-circle-slash-16: + + + Unlike most other devices (laptops, PCs, smartphones, tablets), many IoT are either non-updateable or require + significant effort to update. + + AI/ML systems can be designed to be updated, but it may not always be easy to do so, especially if the system is + dependent on a specific version of a library or other component such as a model sourced from a third party. + + Systems that cannot be updated become less secure over time as new vulnerabilities are found and novel attack + techniques emerge. + Because vulnerabilities are often discovered long after a system has been delivered, systems that lack facilities + for secure updates once deployed present a long-term risk to the networks in which they reside. + This design flaw is perhaps the most significant one already found in many IoT, and if not corrected across the board, + could lead to years if not decades of increasingly insecure devices acting as reservoirs of infection or as + platforms for lateral movement by attackers of all types. | + +!!! warning "Lack of Security Tools" + + **AI/ML** :material-check-all: | + **IoT** :material-check-all: | + **Mobile** :material-check: | + **Web** :octicons-circle-slash-16: | + **Traditional** :octicons-circle-slash-16: + + Security tools used for prevention, detection, analysis, and remediation in traditional computing systems have + evolved and matured significantly over a period of decades. And while in many cases similar concepts apply to IoT and + AI/ML systems, + the practitioner will observe a distinct gap in available tools when attempting to secure or even observe such a + system in detail. + + Packet capture and decoding, traffic analysis, reverse engineering and binary analysis, and the + like are all transferable as concepts if not directly as tools, yet the tooling is far weaker when you get outside + of the realm of Windows and Unix-based (including macOS) operating systems running on x86/IA64 architectures. + This affects both IoT and AI/ML systems, as the latter often run on specialized hardware and software platforms + with similar limitations. + +!!! warning "Vulnerability Scanning Tool and Database Bias" + + **AI/ML** :material-check-all: | + **IoT** :material-check-all: | + **Mobile** :material-check: | + **Web** :material-check: | + **Traditional** :octicons-circle-slash-16: + + + Vulnerability scanning tools largely look for known vulnerabilities. They, in turn, depend on vulnerability + databases for their source material. However, databases of known vulnerabilities—[CVE](https://www.cve.org), + the [National Vulnerability Database](https://nvd.nist.gov) (NVD), [Japan Vulnerability Notes](https://jvn.jp/en/). + (JVN) and the [CERT Vulnerability Notes Database](https://www.kb.cert.org/vuls)—are heavily biased by their + history of tracking vulnerabilities in traditional computing systems (e.g., Windows, Linux, macOS, Unix and variants). + Recent conversations with these and other vulnerability database operators indicate that the need to expand coverage + into Mobile, IoT, AI/ML, and Web systems is either a topic of active investigation and discussion or a work + already in progress. However, we can expect the existing gap to remain for some time as these capabilities ramp up. + +!!! warning "Inadequate Threat Models" + + **AI/ML** :material-check-all: | + **IoT** :material-check-all: | + **Mobile** :material-check: | + **Web** :material-check: | + **Traditional** :material-check: + + Overly optimistic threat models are common among emerging networked systems. + Many AI/ML systems and IoT devices are developed with what can only be described as + naive threat models that drastically underestimate the hostility of the environments into which the system will be + deployed. + + Undocumented threat models are still threat models, even if they only exist in the assumptions made by + the developer. + + Even in cases where the developers of the main system are security-knowledgeable, they are often + composing systems out of components or libraries that may not have been developed with the same degree of security + consideration. This weakness is especially pernicious in power- or bandwidth-constrained systems where the goal of + providing lightweight implementations supersedes the need to provide a minimum level of security. We believe this is + a false economy that only defers a much larger cost when the system has been deployed, vulnerabilities are discovered, + and remediation is difficult. + +!!! warning "Third-party library vulnerabilities" + + **AI/ML** :material-check-all: | + **IoT** :material-check-all: | + **Mobile** :material-check-all: | + **Web** :material-check-all: | + **Traditional** :material-check-all: + + We observe pervasive use of third-party libraries with neither recognition of nor adequate planning for how to fix + or mitigate the vulnerabilities they inevitably contain. When a developer embeds a library into a system, that system + can inherit vulnerabilities subsequently found in the incorporated code. Although this is true in the traditional + computing world, it is even more concerning in contexts where many libraries wind up as binary blobs and are simply + included in the software or firmware as such. This is common to both IoT, where drivers might be included as binary + blobs, and AI/ML, where models might be included as opaque objects. + Lacking the ability to analyze this black box code either in manual source code + reviews or using most code analysis tools, vendors may find it difficult to examine the code's security. + +!!! warning "Unprepared Vendors" + + **AI/ML** :material-check-all: | + **IoT** :material-check-all: | + **Mobile** :material-check-all: | + **Web** :material-check: | + **Traditional** :material-check: + + + Often we find that new vendors are not prepared to receive and handle vulnerability reports from outside parties, + such as the security researcher community. + + Many also lack the ability to perform their own vulnerability discovery within their development lifecycle. + These difficulties tend to arise from one of two causes: + + 1. The vendor is comparatively small or new and has yet to form a product security incident response capability. + 2. The vendor has deep engineering experience in its domain but has not fully incorporated the effect of + network-enabling its products into its engineering quality assurance (this is related to the inadequate threat + model point above). Typically, vendors in this group may have very strong skills in safety engineering or + regulatory compliance, yet their internet security capability is lacking. + + Our experience is that many new vendors are surprised by the vulnerability disclosure process. + We frequently find ourselves having conversations that rehash decades of vulnerability + coordination and disclosure debates with vendors who appear to experience something similar to the + [Kübler-Ross stages of grief](https://en.wikipedia.org/wiki/Five_stages_of_grief) during the process + (denial, anger, bargaining, depression, and acceptance). + +!!! warning "Unresolved Vulnerability Disclosure Debates" + + **AI/ML** :material-check-all: | + **IoT** :material-check-all: | + **Mobile** :material-check-all: | + **Web** :material-check-all: | + **Traditional** :material-check-all: + + In the traditional computing arena, most vendors and researchers have + settled into a reasonable rhythm of allowing the vendor some time to fix vulnerabilities prior to publishing a + vulnerability report more widely. Software as a service (SAAS) and software distributed through app stores can often + fix and deploy patches to most customers quickly. On the opposite end of the spectrum, we find many IoT and embedded + device vendors for whom fixing a vulnerability might require a firmware upgrade or even physical replacement of + affected devices. Conversations with the AI/ML community are even more varied -- it's not always clear what + policy expectations are in that space, nor what "fixing" a vulnerability might mean in that context. + + This diversity of requirements forces vendors and researchers alike to reconsider their expectations + with respect to the timing and level of detail provided in vulnerability reports based on the systems affected + In the past few years, the shift toward IoT has brought different stakeholders into the vulnerability disclosure + debate, and we expect that the AI/ML community will bring even more new perspectives to the table. + + The point is not that there is a single right answer to "resolve the debate". Instead, the CERT/CC emphasizes the + necessity of continuing the conversation and adapting solutions to the diverse needs of the stakeholders, + communities, and the systems they are trying to protect. What works for some groups may not work for others, but + we're committed to helping all parties find a way to work together effectively. + + diff --git a/docs/topics/special/discovery.md b/docs/topics/special/discovery.md new file mode 100644 index 0000000..6b7aa64 --- /dev/null +++ b/docs/topics/special/discovery.md @@ -0,0 +1,99 @@ +# How to Find Vulnerabilities + +Whether you are a security researcher, a product security engineer, or a +vulnerability coordinator, you may be interested in learning about the +techniques commonly used to find vulnerabilities. +Below , we have compiled a list of techniques that are commonly used to find vulnerabilities in +information systems. + +!!! info "About this page" + + In 2014 CERT performed a study of + [vulnerability discovery techniques for IoT systems](https://insights.sei.cmu.edu/blog/vulnerability-discovery-for-emerging-networked-systems/). + As we reviewed the literature, we found a number of techniques in common use. + Many of the techniques listed below are common to vulnerability discovery in the traditional computing and + mobile world. + Some may also prove useful in finding vulnerabilities in AI/ML systems. + +!!! question "Are IoT Systems Really that Different?" + + From a security perspective, even mobile systems have a head start, although they are not as far along as traditional + computing platforms. + The fact is that many of the vulnerabilities found + thus far in IoT would be considered trivial—and rightly so—in the + more mature market of servers and desktop computing. Yet the relative + scale of the IoT market makes even trivial vulnerabilities potentially + risky in aggregate. + +In the tips below, we summarize the techniques we observed in the +literature, ranked in approximately descending order of +popularity at the time. Although it has been a few years since we +conducted this study, we believe that the techniques are still relevant +today, although their relative popularity may have shifted. + +!!! tip "Reading documentation" + + This includes product data sheets, protocol specifications, Internet Drafts and RFCs, manufacturer documentation and + specs, patents, hardware documentation, support sites, bug trackers, discussion forums, FCC filings, developer + documentation, and related information. + +!!! tip "Reverse engineering" + + In most cases, this consists of reverse engineering (RE) binary firmware or other software to understand its function. + However, there are instances in which merely understanding a proprietary file format is sufficient to direct further + analyses. + Hardware RE appears in some research, but has not been as prevalent as RE of software or file formats. + +!!! tip "Protocol analysis" + + Understanding the communication protocols used by a system is vital to identifying remotely exploitable + vulnerabilities. + This technique can take the form of simply sniffing traffic to find mistrusted input or channels, or reverse + engineering a proprietary protocol enough to build a fuzzer for it. + Decoding both the syntax and semantics can be important. + In wireless systems, this technique can also take the form of using a software defined radio (SDR) to perform signal + analysis, which for this purpose is essentially protocol analysis at a lower level of the stack. + +!!! tip "Threat modeling and simulation" + + Threat modeling from the attacker perspective was mentioned in a handful of papers, as was modeling and simulation + of either the system or its protocols for further analysis using mathematical techniques such as game or graph theory. + +!!! tip "Fuzzing" + + Generating randomized input is a common way to test how a system deals with arbitrary input. + Fuzzing network protocols is a common method cited in a number of reports. + +!!! tip "Input or traffic generation and spoofing" + + Unlike fuzzing, spoofing usually consists of constructing otherwise valid input to a system to cause it to exhibit + unexpected behavior. + Constructing bogus input from a valid or trusted source also falls into this category. + +!!! tip "Scanning" + + Because most IoT are composed of multiple components, each of which may have its own architecture and code base, + it is often the case that a researcher can find known vulnerabilities in systems simply by using available + vulnerability scanning tools such as Nessus or Metasploit. + +!!! tip "Hardware hacking" + + This technique involves interfacing directly with the electronics at the circuit level. + It is a form of physical-level reverse engineering and can include mapping circuits and connecting with JTAG to + dump memory state or firmware. + +!!! tip "Debugging" + + This technique uses software-based or hardware-based debuggers. + JTAG is a common hardware debugging interface mentioned in many reports. + +!!! tip "Writing code" + + This technique involves developing custom tools to assist with extracting, characterizing, and analyzing data to + identify vulnerabilities. + +!!! tip "Application of specialized knowledge and skills" + + In some cases, just knowing how a system works and approaching it with a security mindset is sufficient to find + vulnerabilities. + Examples include RFID and ModBus. diff --git a/docs/topics/special/iot_cvd.md b/docs/topics/special/iot_cvd.md new file mode 100644 index 0000000..051c0a5 --- /dev/null +++ b/docs/topics/special/iot_cvd.md @@ -0,0 +1,122 @@ +# IoT and CVD + +!!! info inline end "About this page" + + This IoT-focused CVD page is adapted from two CERT/CC Blog Posts: + [*Vulnerability Discovery for Emerging Networked Systems*](https://insights.sei.cmu.edu/cert/2014/11/-vulnerability-discovery-for-emerging-networked-systems.html) + and + [*What's Different About Vulnerability Analysis and Discovery in Emerging Networked Systems?*](https://insights.sei.cmu.edu/cert/2015/01/-whats-different-about-vulnerability-analysis-and-discovery-in-emerging-networked-systems.html) + +In this section, we turn our attention to the implications that the Internet of +Things brings to the CVD discussion. "Smart things" are expected to +outnumber traditional computers in the near future and will likely +surpass mobile phones not long thereafter. IoT will have implications to +the protection of privacy, opportunities for fraud and abuse, and +ensuring safety. Every vulnerable thing becomes a potential point of +leverage for an attacker to persist or maneuver laterally through a +network. Immature security on IoT devices can leak information that +could allow an attacker to gain a foothold. + +Because many such systems and devices are expected to remain +operationally useful for years or even decades with minimal +intervention, it is especially important that their security be +thoroughly understood prior to deployment. + +!!! quote "Dan Geer, [*Security of Things*](http://geer.tinho.net/geer.secot.7v14.txt), 7 May 2014" + + An advanced persistent threat, one that is difficult to discover, + difficult to remove, and difficult to attribute, is easier in a + low-end monoculture, easier in an environment where much of the + computing is done by devices that are deaf and mute once installed or + where those devices operate at the very bottom of the software stack, + where those devices bring no relevant societal risk by their onesies + and twosies, but do bring relevant societal risk at today's extant + scales much less the scales coming soon. + +## IoT Concerns + +We have observed a number of issues in the course of work done by the +CERT Vulnerability Analysis team. These issues are summarized below. + +
+ +!!! danger "IoT Devices as Black Boxes" + + We identified issues such as the inclusion of networked appliances in a + larger system where the appliances provided networked services based on + sensor data. Enterprise security policy treated the device as a black + box rather than a general-purpose computer with regard to patch levels, + included software, and so forth. The attack vector posed by the sensor + data interface had not been considered either. + +!!! danger "Unrecognized Subcomponents" + + In a number of projects, we observed that while many systems were + composed of highly specified off-the-shelf and custom components, the + vendors providing those systems often could not identify the third-party + subcomponents present in the delivered codebase. The problem can be as + simple as not identifying statically linked libraries or as complicated + as dealing with complex supply chains for code components. + +!!! danger "Long-Lived and Hard-to-Patch" + + We observed various devices with wireless data capabilities embedded + within a larger system yet little or no ability to patch the fielded + systems except within very sparse service windows. Instances where + physical contact with the device is required in order to update it can + be especially problematic once vulnerabilities are discovered + See Dan Geer's [talk](http://geer.tinho.net/geer.secot.7v14.txt) at the Security of Things Forum for more on the + "long-lived and not reachable" problem). + +!!! danger "New Interfaces Bring New Threats" + + We also encountered smart grid devices built out of a traditional + electrical component coupled to an embedded Linux system to provide + networked services. In a deployment context, the device was treated as + an appliance. However, the impact of potential vulnerabilities in the + general-purpose operating system embedded in the device had not been + fully addressed. + +
+ +The threats posed by these systems given their current proliferation trajectory are +concerning. +Even as they become more common, it can be difficult to identify the threats posed to a network by IoT either alone or in +aggregate. + +
+!!! tip "The Hidden Linux Problem" + + In the simplest sense one might think of it as a "hidden + Linux" problem: How many devices can you find in your immediate + vicinity containing some form of Linux? Do you know what their patch + status is? Do you know how you'd deal with a critical vulnerability + affecting them? + +!!! tip "The Third-Party Library Problem" + + Furthermore, while the hidden Linux problem isn't going away any time + soon, we believe the third-party library problem will long outlast it. + How many vulnerable image parsers with a network-accessible attack + vector share your home with you? How would you patch them? + +
+ +## Summarizing the IoT's Impact on CVD + +We anticipate that many of the current gaps in security analysis tools +and knowledge will continue to close over the next few years. However, it +may be some time before we can fully understand how the systems already +available today, let alone tomorrow, will impact the security of the +networks onto which they are placed. The scope of the problem does not +appear to contract any time soon. + +We already live in a world where mobile devices outnumber traditional +computers, and IoT stand to dwarf mobile computing in terms of the sheer +number of devices within the next few years. As vulnerability discovery +tools and techniques evolve into this space, so must our tools and +processes for coordination and disclosure. Assumptions built into the +CVD process about disclosure timing, coordination channels, development +cycles, scanning, patching, and so on, will need to be reevaluated in +the light of hardware-based systems that are likely to dominate the +future internet. diff --git a/docs/topics/special/vul_ids.md b/docs/topics/special/vul_ids.md new file mode 100644 index 0000000..23fa10b --- /dev/null +++ b/docs/topics/special/vul_ids.md @@ -0,0 +1,407 @@ +# Vulnerability IDs and DBs + +The units of work in CVD are vulnerability reports or cases. However, a +single case may actually address multiple vulnerabilities. Teasing out +how many problems are involved in a report can be tricky at times. The +implications of this in terms of the CVD process and the compilation of +vulnerability databases is significant. + +This section is adapted from a [CERT/CC blog post](https://insights.sei.cmu.edu/blog/vulnerability-ids-fast-and-slow/). + +## On the Complexities of Vulnerability Identity + +Vulnerability identifiers can serve multiple purposes. + +They may be used to identify the following: + +- A vulnerability report or case +- A document or database entry that describes a vulnerability (e.g., + [CERT Vulnerability Notes](https://www.kb.cert.org/vuls)) +- The [specific flaw](https://www.cve.org) that such a document or report describes + +```mermaid +--- +title: What is being identified? +--- +erDiagram + case["A Report or Case"] + doc["A Document or Database Entry"] + flaw["A Specific Flaw"] +``` + +Now this isn't really a problem as long as one case describes one +vulnerability and that case results in the creation of one document. But +that's not always the case, for a number of reasons, including those +below: + +- Different processes use different abstractions to define what "unit + vulnerability" is. For example, CVE has [specific guidance](https://www.cve.org/ResourcesSupport/AllResources/CNARules) on + counting rules. + +- It's rare for vendors to release single-issue patches. More often + they prefer to roll up multiple fixes into a single release, and + then publish a document about the release. + +- In the case of independent discovery, or at least duplicate + reporting, multiple cases may be opened describing the same + vulnerability. In some instances, this fact may not become obvious + until considerable effort has been put into isolating the bugs in + each report. For example, a single vulnerability can manifest in + different ways depending on how it's triggered. The connection + might only be discovered on root cause analysis. + +- Automated testing such as fuzzing can lead to rapid discovery of + very large numbers of unique failure cases that are difficult to + resolve into specific bugs. + +```mermaid +--- +title: Actual Relationships +--- +erDiagram + case["A Report or Case"] + doc["A Document or Database Entry"] + flaw["A Specific Flaw"] + case }o--o{ doc : "leads to" + doc }o--|{ flaw : "describes" + case }|--o{ flaw : "describes" +``` + +!!! example "Automated Testing" + + Automated testing can also identify so many individual vulnerabilities + that human-oriented case handling processes cannot scale to treat each + one individually. + Here's an extreme example of this phenomenon: + although the CERT/CC published only a single Vulnerability Note + [VU#582497](https://www.kb.cert.org/vuls/id/582497) for + Android apps that failed to validate SSL certificates, in the end it + covered 23,667 [vulnerable apps](https://docs.google.com/spreadsheets/d/1t5GXwjw82SyunALVJb2w0zi3FoLRIkfGPc7AMjRF0r4). Should each get its own + identifier? Yes, and we did assign individual VU# identifiers to each + vulnerable app. But this highlights the distinction between the + vulnerability and the document that describes it. + +!!! info "AI/ML and Vulnerability Identification" + + We have recently been exploring the implications of vulnerability identification + in Artificial Intelligence and Machine Learning (AI/ML) systems. + In our 2021 paper [*On managing vulnerabilities in AI/ML systems*](https://doi.org/10.1145/3442167.3442177), + we discuss a number of challenges in identifying vulnerabilities in AI/ML systems, including the + difficulty of localizing the source of a vulnerability in a complex system to a specific component. + We expect to have more to say on this topic in the future. + +!!! info "Prior work: Vulnerability Cross-Reference (VXREF)" + + When this content was first published, work was underway within the + [Vulnerability Report Data Exchange](https://www.first.org/global/sigs/vrdx/) + special interest group (VRDX-SIG) + within [FIRST](https://www.first.org/) on a vulnerability report cross-reference data model that + would allow for the expression of relationships between vulnerability + reports. That work has since concluded, and the resulting data model + can be found on Github at [FIRSTdotorg/vrdx-sig-vxref-wip](https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip) + + In order to make it easier to relate vulnerability reports and records + to each other, the VXREF work represents the following concepts: + `possibly related`, `related`, `not equal`, `equal`, `superset`, `subset`, and `overlap`. + +!!! warning "What CVE Isn't" + + Because of the prevalence and popular use of CVE IDs in the + vulnerability response space, many people assume that vulnerability + identity is synonymous with [Common Vulnerabilities and Exposures](https://www.cve.org) (CVE). + However, let's briefly look at some ways in which that assumption is inaccurate: + + - CVE has limited scope of coverage. + - Not all known vulnerabilities are assigned a CVE ID. + +## Every Vulnerability Database Makes Choices + +As the CERT/CC's vulnerability analysis efforts have expanded into +[vulnerability coordination for non-traditional computing products](https://insights.sei.cmu.edu/blog/coordinating-vulnerabilities-iot-devices/) +(mobile, vehicles, medical devices, IoT, ΑΙ/ΜL, etc.), we've also begun +to hit up against another set of issues affecting vulnerability +identities and compatibility across vulnerability databases (VDBs): +namely, bias. + +!!! info "Buying Into the Bias: Why Vulnerability Statistics Suck" + + Steve Christey Coley and Brian Martin mention a number of biases that + affect all VDBs in their BlackHat 2013 talk ([video](https://www.youtube.com/watch?v=3Sx0uJGRQ4s)|[pdf](https://media.blackhat.com/us-13/US-13-Martin-Buying-Into-The-Bias-Why-Vulnerability-Statistics-Suck-WP.pdf)): + + - **Selection bias**. Not all products receive equal scrutiny. Not all + vul reports are included in VDBs. + - **Publication bias**. Not all results get published. Some vuls are + found but never reported to anyone. + - **Abstraction bias**. This bias is an artifact of the process that + VDBs use to assign identifiers to vulnerabilities. (Is it 1 vul or + 3?, 23,667 or 1?) + - **Measurement bias**. This bias encompasses errors in how a + vulnerability is analyzed, verified, and catalogued. + +Ideally, bias would be factored into analytical results based on the data collected. +But VDBs don't exist solely in the service of scientific purity. +Every vulnerability database or catalog makes choices driven by the business requirements and organizational +environments in which those VDBs operate. + +These choices include the following: + +
+ +- **Sources of vulnerability information monitored** + + --- + Monitoring all + the potential sources of vulnerability information is unrealistic + for resource-constrained VDBs; to date we have found none that are + not so constrained. This choice is one source of selection bias. + +- **Inclusion and exclusion criteria** + + --- + Rules that define what subset + of records from the sources monitored will be included (or not) in + the VDB must be decided. What kind of vulnerabilities does the VDB + track? Is it platform specific? Is it just a single vendor + collecting reports in its own products? Is it focused on a + particular business sector? This choice is another source of + selection bias. + +- **Content detail** + + --- + How much (and what kind of) detail goes into + each record in a VDB is something that must be decided: for example, + whether to include exploit information, workarounds, detection + criteria, and so forth. + +- **Abstraction** + + --- + What is a "unit" vulnerability? Does this report + represent one vul or many? That choice depends on what purpose the + VDB serves. Christey and Martin cover this issue in their list of + biases, describing it as "the most prevalent source of problems for + analysis." + For example, the CVE program has specific [assignment rules](https://www.cve.org/ResourcesSupport/AllResources/CNARules). + +
+ +!!! note "Different Contexts, Different Choices" + + Even if two vulnerability databases agree + on these first four items, over time it's easy to wind + up with completely distinct data sets due to next four. + +
+- **Uncertainty tolerance** + + --- + How certain is the information included + in the record? Is the goal of the VDB to be authoritative on first + publication? Or can it tolerate being wrong sometimes in favor of + getting things out more quickly? + +- **Latency tolerance** + + --- + How quickly do new records need to be placed + in the VDB following the initial disclosure? This choice is a + distinct tradeoff with uncertainty: consider the differences between + breaking news coverage and a history book. + +- **Capacity constraints** + + --- + For a VDB, incoming vulnerability report volume is + unconstrained while the capacity to consume and process those + reports into database records is decidedly not (especially with + humans in the loop, and as of this writing they still are). + +- **Users and consumers of the data** + + --- + Ultimately, a VDB must serve + some useful purpose to some audience in order for it to continue to + exist. There is a wide variety of uses for the information contained + in VDBs (vulnerability scanning, vulnerability management systems, + long-term trend analysis, academic research, quality improvement + efforts, supporting acquisition or purchasing decisions, evaluating + vendor process effectiveness, etc.), so it shouldn't be surprising + that user requirements can drive many of the other choices the VDB + operators have to make. + +
+ +## Where We Are vs. Where We Need to Be + +The vulnerability databases you are probably most familiar with, such as +the [National Vulnerability Database](https://nvd.nist.gov) (NVD), +[Common Vulnerabilities and Exposures](https://www.cve.org) (CVE), and the +[CERT Vulnerability Notes Database](https://www.kb.cert.org/vuls) +have historically focused on vulnerabilities affecting +traditional computing platforms (Windows, Linux, OS X, and other +Unix-derived operating systems) with only a smattering of coverage for +vulnerabilities in other platforms like mobile or embedded systems, +websites, and cloud services. + +In the case of websites and cloud services +this gap may be acceptable since most such services are effectively +single instances of a large-scale distributed system and therefore only +the service provider needs to apply a fix. In those cases, there might +not be a need for a common identifier since nobody is trying to +coordinate efforts across responsible parties. But in the mobile and +embedded spaces, we definitely see the need for identifiers to serve the +needs of both disclosure coordination and patch deployment. + + +Furthermore, there is a strong English language and English-speaking +country bias in the major U.S.-based VDBs (hopefully this isn't +terribly surprising). China has not one but two major VDBs: [China +National Vulnerability Database of Information Security](https://en.wikipedia.org/wiki/Chinese_National_Vulnerability_Database) (CNNVD) +and [China National Vulnerability Database](http://www.cnvd.org.cn/) (CNVD). +We have been +working with CSIRTs around the world (e.g., [JPCERT/CC](https://www.jpcert.or.jp/english/) +and [NCSC-FI](https://www.viestintavirasto.fi/en/cybersecurity.html) +to coordinate vulnerability response for years and realize the +importance of international cooperation and interoperability in +vulnerability response. + +Given all the above, and in the context of the +surging prevalence of bug bounty programs, it seems likely that in the +coming years there will be more, not fewer VDBs around the world than +there are today. We anticipate those VDBs will cover more products, +sectors, languages, countries, and platforms than VDBs have in the past. + +Coordinating vulnerability response at local, national, and global +scales requires that we have the means to relate vulnerability reports +to each other, regardless of the process that originated them. +Furthermore, whether they are driven by national, commercial, or +sector-specific interests, there will be a need for interoperability +across all those coordination processes and the VDBs into which they +feed. + +## Vulnerability IDs, Fast and Slow + +Over time, it has become clear that the days of the "One Vulnerability +ID to Rule Them All" are coming to a close and we need to start +planning for that change. As we've covered above, one of the key +observations we've made has been the growing need for multiple +vulnerability identifiers and databases that serve different audiences, +support diverse business practices, and operate at different +characteristic rates. + +In his book [*Thinking, Fast and Slow*](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow), Daniel Kahneman +describes human thought processes in terms of two distinct systems: + +```mermaid +--- +title: Kahneman's Two Systems +--- +flowchart TD + subgraph sys1["System 1"] + fast["Fast"] + auto["Automatic"] + freq["Frequent"] + emo["Emotional"] + ste["Stereotypic"] + sub["Subconscious"] + end + subgraph sys2["System 2"] + slow["Slow"] + eff["Effortful"] + infreq["Infrequent"] + log["Logical"] + calc["Calculating"] + con["Conscious"] + end + fast -.- slow + auto -.- eff + freq -.- infreq + emo -.- log + ste -.- calc + sub -.- con +``` + +Making the analogy to CVD processes, notice that historically there has +been a need for slower, consistently high-quality, authoritative +vulnerability records, trading off higher latency for lower noise. +Deconfliction of duplicate records happens before an ID record (e.g., a +CVE record) is issued, and reconciliation of errors can be difficult. To +date, this practice is the ideal for which many VDBs have strived. Those +VDBs remain a valuable resource in the defense of systems and networks +around the globe. + +!!! question "Do we need a *System 1* for vulnerability IDs?" + + Yet there is a different ideal, just as valid: one in which + vulnerability IDs are assigned quickly, possibly non-authoritatively, + and based on reports of variable quality. This process looks more like + "issue first, then deconflict." For this new process to work well, post-hoc + reconciliation needs to become easier. + + + Such a process might be more like a newsroom than a history book. It's + more about getting the information out quickly than getting it right + the first time. That's not to advocate for sloppiness, but rather to + recognize that the need for quick response is sometimes more important + than the need for perfect response. + + In the long run, assigning IDs quickly can facilitate coordinated response to a + vulnerability, but it can also lead to confusion if the IDs are + incorrect or if the same vulnerability is assigned multiple IDs. This + is where a reconciliation process would need to come in. + By the time the dust + settles, correct IDs should be assigned and incorrect ones would be deprecated. + +## A Path Toward VDB Interoperability + +As mentioned above, the FIRST [VRDX-SIG](https://www.first.org/global/sigs/vrdx/) +worked on a vulnerability cross-reference scheme that would allow for +widely distributed +vulnerability ID assignments and VDBs to run at whatever rate is +necessary, while enabling the ability to reconcile them later once the +dust clears: + +- When necessary, the CVD process could operate in System 1 for quick + response, and clean up any resulting confusion afterwards. +- A tactical response-focused VDB might be able to tolerate more + uncertainty in trade for lower latency. +- A VDB with more academic leanings could do a deep-dive analysis on + root causes in exchange for having fewer records and higher latency. + +The main idea was that VDB records can be related to each other in one +of the following ways: + +- **possibly related** - not enough information to rule out a relationship +- **related** - related but unspecified how +- **equality** and **inequality** - two records describe the same vulnerability + or vulnerabilities, or they refer to different ones +- **superset** and **subset** - one record is more abstract than the other +- **overlap** - related but not fully contained + +This work built on both prior work at the CERT/CC and Harold Booth and +Karen Scarfone's October 2013 IETF Draft [Vulnerability Data Model](https://datatracker.ietf.org/doc/draft-booth-sacm-vuln-model/02/). +However, while it would be great if we could get to a unified +data model like the IETF draft for vulnerability information exchange +eventually, at the time the simplest thing that could possibly work seemed +to be coming up with a way to relate records within or between +vulnerability databases that explicitly addresses the choices and biases +described above. The unified data model might be a longer way off, and +we were anticipating the need to reconcile VDBs much sooner. + +## Looking Ahead + +While it's hard to say how we'll get there, it seems +likely that we'll eventually reach a point where vulnerability IDs +can be issued (and deconflicted) at the speed necessary to improve +coordinated global vulnerability response while maintaining our ability +to have high-quality, trusted sources of vulnerability information. + +Here in the CERT/CC Vulnerability Analysis team, we recognize the need +for slower, "correct-then-issue" vulnerability IDs as well as faster +moving "issue-then-correct" IDs. We believe that there is room for +both (and in fact many points in between). We +intend to continue our efforts to build a better way forward that suits +everyone who shares our interest in seeing that vulnerabilities get +coordinated and disclosed, and that patches are created and deployed, +all with an eye toward minimizing societal harm in the process. diff --git a/docs/tutorials/coord_certcc/index.md b/docs/tutorials/coord_certcc/index.md new file mode 100644 index 0000000..de912df --- /dev/null +++ b/docs/tutorials/coord_certcc/index.md @@ -0,0 +1,145 @@ +# Coordinating via CERT/CC + + +Coordinating with the CERT/CC isn't much different from coordinating directly with a vendor, but there are a few extra steps. +This page will walk you through the process of coordinating with the CERT/CC, and what to expect when working with us. + + +{% include-markdown "../../_includes/_what_is_coord.md" heading-offset=1 %} + +When working with the CERT/CC, the process is typically very similar to what +we laid out in [Disclosure 101](../response_process/index.md), but with a few +extra steps: + +1. Security researcher reports a vulnerability to the CERT/CC and + requests coordination assistance +2. CERT/CC analyzes the report, attempting to verify correctness of + information, and deciding if will accept or decline to provide + assistance + + - CERT/CC may decline to assist in otherwise valid reports for + many reasons: low severity, resource/time constraints, etc. + +3. If the report is accepted by the CERT/CC, then the CERT/CC will + attempt to contact the vendor and report the vulnerability + + ```mermaid + flowchart LR + reporter([Reporter]) + certcc([CERT/CC]) + decide{ } + + vendor([Vendor]) + reporter -->|1 report| certcc + certcc -->|2 assist?| decide + decide -->|2a yes
3 report| vendor + decide -->|2b no
notify| reporter + ``` + +4. CERT/CC begins planning on public disclosure as a [Vulnerability Note](https://www.kb.cert.org/vuls) + after an embargo period, typically 45 days from initial date of attempted contact, or another + date negotiated with the reporter. +5. If the vendor replies, CERT/CC will work with the vendor to develop + and test patches if necessary, as well as help notify any downstream + vendors affected + + - If the vendor does not reply, CERT/CC will attempt to alert + downstream vendors prior to the disclosure date and then publish + the Vulnerability Note after sending a reminder notice to the + vendor + +6. If possible, CERT/CC and the vendor will provide the patch for the + vulnerability to downstream vendors privately before public + disclosure + + ```mermaid + flowchart LR + reporter([Reporter]) + vendor([Vendor]) + certcc([CERT/CC]) + downstream([Downstream Vendors]) + certcc -->|4 set embargo| certcc + certcc <-->|4 set embargo| reporter + certcc -->|4 set embargo| vendor + vendor <-->|5 develop patch| certcc + certcc -->|5a report| downstream + vendor -->|6 provide patch| downstream + ``` + +7. Prior to the publication date, a CVE ID is assigned by CERT/CC if + necessary + + - unless the vendor is a CVE Numbering Authority, in which case the vendor should assign the CVE ID. + +8. The draft Vulnerability Note and CVE ID are shared with the vendor + and reporter for comments, typically 1-2 weeks before the + publication date. In some scenarios, CERT/CC may decide not to + publish, however. +9. On the agreed-upon publication date, public security advisories are + published, detailing the issue and how to obtain the patch or + mitigate the issues. CERT/CC may publish a Vulnerability Note, and + typically the vendor and/or the reporter will also publish their own + advisories. +10. Depending on who made the assignment in step 7, either the vendor or CERT/CC will create a CVE record for the + vulnerability, which will be shared with the CVE List +11. The NVD publishes an entry for the CVE ID + +```mermaid +flowchart TD + reporter([Reporter]) + vendor([Vendor]) + certcc([CERT/CC]) + downstream([Downstream Vendors]) + cve([CVE List]) + nvd([NVD]) + public([Public]) + certcc -.->|7 assign CVE ID| certcc + vendor -->|7 assign CVE ID| vendor + certcc -->|8 share draft| vendor + certcc -->|8 share draft| reporter + certcc -->|8 share draft| downstream + certcc -.->|9 publish| public + reporter -->|9 publish| public + vendor -->|9 publish| public + downstream -->|9 publish| public + vendor -->|10 CVE record| cve + certcc -.->|10 CVE record| cve + cve -->|10 CVE record| nvd + cve -->|10 CVE record| public + nvd -->|11 NVD entry| public +``` + +{% include-markdown "../../_includes/_certcc_policy_tip.md" heading-offset=1 %} + +{% include-markdown "../../_includes/_report_certcc.md" heading-offset=1 %} + +!!! note "Coordination with CERT/CC" + + Please note that when a vulnerability is reported to the CERT/CC, we + will begin to manage the process and timeline. We will take reporter's + comments into our decision process, but by submitting a report, the + reporter agrees that CERT/CC has final decision authority over any + coordination and publishing on [kb.cert.org](https://www.kb.cert.org/vuls), + and agree to follow our [Disclosure Policy](../../reference/certcc_disclosure_policy.md) + by default. However, as the vulnerability reporter, you + are the owner of the vulnerability information and are free to disclose + it on your own at any time, if you wish. + + Per our disclosure policy, we also reserve the right to change this + process as necessary. As stated earlier, every case is somewhat unique + and may require significant changes to the process depending on the + information available. + +
+ +!!! question "I'm a reporter, what should I do next?" + + See the [Reporter Response Process](../response_process/reporter.md) for more information on what to do when you find a vulnerability. + If you've reviewed that and still need our help, see [Requesting Coordination Assistance from the CERT/CC](./reporter.md). + +!!! question "I'm a vendor, what should I do next?" + + See the [Vendor Response Process](../response_process/vendor.md) for more information on what to do when you receive a vulnerability report. + See [Working with the CERT/CC](./vendor.md) for more information on how to engage with the CERT/CC. + +
diff --git a/docs/tutorials/coord_certcc/reporter.md b/docs/tutorials/coord_certcc/reporter.md new file mode 100644 index 0000000..481bc2f --- /dev/null +++ b/docs/tutorials/coord_certcc/reporter.md @@ -0,0 +1,141 @@ +# Requesting Coordination Assistance from the CERT/CC + +!!! note "Prerequisites" + + Review [Reporter Response Process](../response_process/reporter.md) first. + +This tutorial picks up where the [Reporter Response Process](../response_process/reporter.md) leaves off. +It is intended for vulnerability reporters who have found a vulnerability and are requesting coordination assistance from the CERT/CC. + +{% include-markdown "../../_includes/_what_is_coord.md" heading-offset=1 %} + +## Before Submitting a Request to the CERT/CC + +Some things to consider before submitting a request to the CERT/CC: + +!!! question "Have you contacted the vendor?" + + We usually recommend that a reporter first try reporting the + vulnerability directly to the vendor or maintainer of the software in + question. See the [response process for reporters](../response_process/reporter.md) for more information. + +!!! warning "Non-Disclosure Agreements" + + Please note that as a security researcher or penetration tester, you or your company may be subject to a + Non-Disclosure Agreement (NDA) regarding vulnerabilities you find. + Please investigate this possibility and consider any legal implications of an NDA before reporting a vulnerability. + +{% include-markdown "../../_includes/_eff_advice.md" heading-offset=1 %} + +{% include-markdown "../../_includes/_certcc_policy_tip.md" heading-offset=1 %} + +```mermaid +flowchart TD + reporter([Reporter]) + certcc([CERT/CC]) + reporter -->|requests
coordination| certcc + decide{ } + accept[[Coordinate]] + decline[[Decline]] + certcc -->|accept?| decide + decide -->|yes| accept + decide -->|no| decline +``` + +!!! info "Initial Response Time" + + The CERT/CC typically responds to requests within 24-48 hours. Depending on the request, further analysis and decision may take additional time. + +## How does the CERT/CC decide if we will accept a request? + +The CERT/CC attempts to take a balanced approach to the +numbers and types of vulnerabilities handled in order to maximize +benefit to the global community. + +!!! info "Declining Reports" + + The CERT/CC always reserves the right to decline to assist in coordination or to publish, especially for low priority reports or reports that are lacking information. + +Even if a high quality vulnerability report is submitted, we may still +decline to assist. This is not a reflection on the reporter or the +quality of the report, but rather a result of limited time and +resources. + +Some common reasons for us to decline a request include: + +
+ +- **Low CVSS score** + + --- + We evaluate the CVSS v2 Environmental score for all new reports, + and use this score to help set priorities on reports. We + generally place more emphasis on vulnerabilities with higher + scores, and generally decline reports with low Environmental + scores. For more information on how to perform CVSS scoring on + your vulnerability, please see the [CVSS website](http://www.first.org/cvss). + + One result of CVSS Environmental scoring is that software that + is not widely distributed (i.e., has a very small global user + base) will often be declined. + +- **Lack of strong evidence** + + --- + Evidence must be provided before action can be taken. Reports + lacking a proof of concept or proposed patch will be considered + low priority or even declined. + +- **Only a CVE ID is needed** + + --- + The CERT/CC typically only provides CVE IDs for vulnerabilities + we take an active role in coordinating. Reports only requesting + a CVE ID will generally be declined. CVE IDs can be requested + directly from the [CVE project](https://www.cve.org/ReportRequest/ReportRequestForNonCNAs). + +- **Only publication is requested** + + --- + The CERT/CC typically only publishes on vulnerabilities we take + an active role in coordinating, and will generally decline + reports on an already substantially coordinated issue. + +
+ +Please be aware of these guidelines when submitting a request to the +CERT/CC. + +## What happens next? + +If the request is accepted, the CERT/CC will begin reaching out to the +vendor(s). The CERT/CC will then work with them as necessary to develop +a patch and provide this patch to the community. The CERT/CC may decide +to publish a [Vulnerability Note](https://www.kb.cert.org/vuls) on your vulnerability at the end of the +process, depending on the circumstances. + +Please note that when a vulnerability is reported to the CERT/CC, we +will take the reporter's comments into our decision process, but by +submitting a report, the reporter agrees that CERT/CC has final decision +authority over any coordination and publishing on the [kb.cert.org](https://www.kb.cert.org) +website. + +!!! note "Reporter's Right to Disclose" + + As the vulnerability reporter, you are the owner of the + vulnerability information and are free to disclose it on your own at any + time, if you wish. + +## What if the CERT/CC declines my report? + +If your vulnerability report is declined by the CERT/CC, we still +encourage you to attempt contact with the vendor or maintainer. + +If your contact attempt fails despite acting responsibly, you may +consider self-publishing (on a personal blog or website) information +about your vulnerability, or perhaps submitting information about your +vulnerability to a security mailing list such as +[Full Disclosure](http://seclists.org/fulldisclosure/). If you do, please take care regarding how much +information is released; ideally, provide only enough information for +users to understand the issue and mitigate attacks, but not a full +proof-of-concept that can be misused. diff --git a/docs/tutorials/coord_certcc/vendor.md b/docs/tutorials/coord_certcc/vendor.md new file mode 100644 index 0000000..48cbc30 --- /dev/null +++ b/docs/tutorials/coord_certcc/vendor.md @@ -0,0 +1,98 @@ +# Working with the CERT/CC + +!!! info "Prerequisites" + + Review [Vendor Response Process](../response_process/vendor.md) first. + +If you have received a notification from the CERT/CC about a vulnerability in your product, +you are likely looking for guidance on how to respond. +This page provides an overview of the process for working with the CERT/CC to address the vulnerability. + +## Responding to a CERT/CC Vulnerability Notification + +{% include-markdown "../../_includes/_certcc_policy_tip.md" heading-offset=1 %} + +{== TODO review for accuracy given VINCE ==} +After reviewing the vulnerability report submitted, you can respond by +sending an email to [cert@cert.org.](mailto:cert@cert.org). +When doing so, be sure to include your VU# in the subject line, so that +our automated system can route your response to the analyst handling +your case. If you forget to add the VU# to the subject line of your +response email, our response may be delayed significantly. + +{== TODO review for accuracy given VINCE ==} +We recommend encrypting your response email to +[cert@cert.org](mailto:cert@cert.org) with the CERT/CC\'s [PGP public key], in order to +maintain privacy until the public disclosure date. For more information +on using PGP or obtaining the CERT/CC's PGP key, please see [Sending +Sensitive Information](http://www.cert.org/contact/sensitive-information.cfm). + +{== TODO review for accuracy given VINCE ==} +To fully communicate with the CERT/CC in a secure manner, we need your +organization's most up-to-date contact information, including your own +PGP public key. To update your information with us, please see our +[VINCE FAQ](https://vuls.cert.org/confluence/display/VIN/Frequently+Asked+Questions). + +!!! tip "What does the CERT/CC look for in a response?" + + Typically, we would like the following questions answered in your + organization's response: + + - Is this report indicative of a real vulnerability? If not, can you + provide details why you do not believe it is a vulnerability? + - Has this vulnerability already been addressed in a recent or + upcoming release? + - If the vulnerability has not been addressed yet, when might the fix + be available? + - Do you need any further information from the CERT/CC or the reporter + in order to address this issue? + + {== TODO review for accuracy given VINCE ==} + If you require extra information from the CERT/CC before a determination + can be made, please feel free to contact us. The best way to do so is to + send an email to [cert@cert.org](mailto:cert@cert.org) + with your VU# in the subject line, asking for more + information. You may also call our phone number during business hours + and an analyst will follow up with your message. + + We may also be able to arrange conference calls with analysts, or use + other communication methods if requested. + +## Publications and Vulnerability Disclosure + +After 45 days or another agreed upon timeline, we publish +[Vulnerability Notes](http://www.kb.cert.org/vuls/) +to disclose the vulnerability and information on addressing the vulnerability if available. + +!!! tip "Vendor Statements Are Welcome" + + We welcome Vendor Statements on any Vulnerability Note, even if the Note + is already published. The Vendor Statement can consist of any statement + or information you wish; we will copy this statement verbatim into our + published Vulnerability Note. + + {== TODO review for accuracy given VINCE ==} + To send a Vendor Statement, please email + us at [cert@cert.org](mailto:cert@cert.org) with the VU# of the vulnerability in the subject line, + and include you statement in the body of the email. This email should be + PGP signed by your organization's key so we may verify its + authenticity. + +## Multiparty Coordination + +The CERT/CC often coordinates with multiple vendors when a vulnerability +affects more than one product. +We refer to this as [Multiparty Coordinated Vulnerability Disclosure](../../howto/coordination/mpcvd.md) (MPCVD). + +We can help coordinate the response to ensure that all affected parties are aware of the vulnerability and are +working to address it. + +!!! tip "Coordinating with Other Vendors" + + If you discover a vulnerability that might affect more products than + just your own (for example, you find a vulnerability in a widely-used + open source library), please feel free to reach out to us to coordinate + with all vendors at once. + {== TODO review for accuracy given VINCE ==} + If desired, we can keep your organization anonymous when coordinating with other + vendors. diff --git a/docs/tutorials/cvd_in_a_nutshell.md b/docs/tutorials/cvd_in_a_nutshell.md new file mode 100644 index 0000000..bc25924 --- /dev/null +++ b/docs/tutorials/cvd_in_a_nutshell.md @@ -0,0 +1,54 @@ +# The *CERT Guide to CVD* in a Nutshell + +Software-based products and services have vulnerabilities—conditions +or behaviors that allow the violation of an explicit or implicit +security policy. This should come as no surprise to those familiar with +software. What many find surprising nowadays is just how many products +and services should be considered *software based*. The devices we depend +on to communicate and coordinate our lives, transport us from place to +place, and keep us healthy have in recent years become more and more +connected both to each other and to the world at large. As a result, +society has developed an increasing dependence on software-based +products and services along with a commensurate need to address the +vulnerabilities that inevitably accompany them. + +Adversaries take advantage of vulnerabilities to achieve goals at odds +with the developers, deployers, users, and other stakeholders of the +systems we depend on. Notifying the public that a problem exists without +offering a specific course of action to remediate it can result in +giving an adversary the advantage while the remediation gap persists. +Yet there is no optimal formula for minimizing the potential for harm to +be done short of avoiding the introduction of vulnerabilities in the +first place. In short, vulnerability disclosure appears to be a [wicked +problem](../topics/principles/wicked_problem.md). + +Coordinated Vulnerability Disclosure (CVD) is a process for reducing +adversary advantage while an information security vulnerability is being +mitigated. [CVD is a process, not an event.](cvd_is_a_process.md) Releasing a patch or +publishing a document are important events within the process, but do +not define it. + +{% include-markdown "../_includes/_core_questions_of_cvd.md" heading-offset=1 %} + +CVD should not be confused with [Vulnerability Management](terms/vulnerability_management.md) (VM). +VM encompasses the process downstream of CVD, once the vulnerability has +been disclosed and deployers must take action to respond. + +!!! info "What's on this Page?" + + The _CERT Guide to CVD in a Nutshell_ provides an overview of many of the topics covered + later in this documentation, with links to more detailed information. We're providing + it here as a preview of what's to come as you work through the remainder of the site. + +{% include-markdown "../topics/index.md" heading-offset=1 %} +{% include-markdown "../howto/index.md" heading-offset=1 %} + +{% include-markdown "../reference/index.md" heading-offset=1 %} diff --git a/docs/tutorials/cvd_is_a_process.md b/docs/tutorials/cvd_is_a_process.md new file mode 100644 index 0000000..bf99f03 --- /dev/null +++ b/docs/tutorials/cvd_is_a_process.md @@ -0,0 +1,50 @@ +# Coordinated Vulnerability Disclosure is a Process, Not an Event + +Publishing a document is an action. Releasing a +fix is an action. And while both of these are common events within the +CVD process, they do not define it. + +## A Simple Description of the CVD Process + +Perhaps the simplest description of +the CVD process is that it starts with at least one individual becoming +aware of a vulnerability in a product. This discovery event immediately +divides the world into two sets of people: + +```mermaid +flowchart TD + a([Everybody]) + b([Those who know
about the vulnerability]) + c([Those who don't know
about the vulnerability]) + a -->|Finds out| b + a -->|Doesn't find out| c + + +``` + +From that point on, those belonging to the set that knows about the vulnerability iterate on two questions: + +{% include-markdown "../_includes/_core_questions_of_cvd.md" %} + +Simple enough? Hardly. If it were, this documentation would be considerably +shorter. But with this simple iterator in mind, we'll be better able to +frame our discussion. + +## Who's Involved in the CVD Process? + +!!! tip inline end "Roles in CVD" + + See [Roles in CVD](../topics/roles/index.md) for a more detailed discussion of the roles involved in the CVD process. + +Ideally, product and service vulnerabilities would be either discovered +by the vendor (developer) of the software product or service itself or +reported to the vendor by a third party (finder, reporter). Informing +vendors enables them to take action to address and correct +vulnerabilities. In most cases, the vendor is the party best suited to +correct the vulnerability at its origin. Vendors typically remediate +vulnerabilities by developing and releasing an update to the product, +also known as a patch. However, often the vendor issuing an update is +a step in the middle of a process that starts with discovery and moves +towards remediation of the installed base of vulnerable systems. +Deployers must still ensure that patches are +deployed in a timely manner to the systems they need to protect. diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md new file mode 100644 index 0000000..0af01ce --- /dev/null +++ b/docs/tutorials/index.md @@ -0,0 +1,84 @@ +# Introduction + +Imagine you've found a vulnerability in a product. What do you do with +this knowledge? + +Maybe nothing. There are many situations in which it's perfectly +reasonable to decide to go on about your business and let somebody else +deal with it. + +!!! info inline end "The First Decision in Coordinated Vulnerability Disclosure" + + The first decision in Coordinated Vulnerability Disclosure is whether to start the process at all. + + ```mermaid + stateDiagram-v2 + direction TB + found: I know about
a vulnerability + state decide <> + [*] --> found + found --> decide: What to do? + coordinate: CVD + decide --> [*] : Do nothing + decide --> coordinate: Coordinate + ``` + +- You're busy. +- You have more important things to do. +- It's not your code, so it's not your problem. +- Or maybe it is your code, but you wrote it a long time ago, and it will take a lot of effort to even +try to fix it. +- Maybe the product has already reached end-of-life. +- Or perhaps fixing this bug will delay the launch of your new product that will supersede this version anyway. + +There are plenty of good reasons +that it might not be worth the hassle of fixing it or reporting it. +Although this is what a mathematician would refer to as a degenerate +case of the disclosure process in which no disclosure occurs, it's +important to recognize that even *starting* the process of disclosure is a +choice one must consider carefully. + +Often, though, you will likely feel a need to take some action in +response to this newfound knowledge of a vulnerability. If it's your +product, you might immediately set off to understand the root cause of +the problem and fix it. Once fixed, you probably will want to draw +attention to the fix so your product's users can protect themselves. Or +perhaps the product is other people's responsibility to fix, and you +want to inform them of the existence of this vulnerability. + +This is where the process of Coordinated Vulnerability Disclosure (CVD) +begins. + +## Where to go from here + +The remainder of this section provides some tutorials and guidance on how to get started with +Coordinated Vulnerability Disclosure. + +
+ +- :octicons-squirrel-16: [**The CERT Guide to CVD in a Nutshell**](./cvd_in_a_nutshell.md) + + --- + {% include-markdown "./cvd_in_a_nutshell.md" start="" end="" %} + +- :material-motion-outline: [**Coordinated Vulnerability Disclosure is a Process, Not an Event**](./cvd_is_a_process.md) + + --- + {% include-markdown "./cvd_is_a_process.md" start="" end="" %} + +- :material-format-list-bulleted-triangle: [**CVD Terminology**](./terminology.md) + + --- + {% include-markdown "./terminology.md" start="" end="" %} + +- :material-stairs-up: [**Vulnerability Response Processes**](./response_process/index.md) + + --- + {% include-markdown "./response_process/index.md" start="" end="" %} + +- :material-escalator-up: [**Coordinating with the CERT/CC**](./coord_certcc/index.md) + + --- + {% include-markdown "./coord_certcc/index.md" start="" end="" %} + +
diff --git a/docs/tutorials/response_process/deployer.md b/docs/tutorials/response_process/deployer.md new file mode 100644 index 0000000..8937413 --- /dev/null +++ b/docs/tutorials/response_process/deployer.md @@ -0,0 +1,143 @@ +# Deployer Vulnerability Response Process + +A [deployer](../../topics/roles/deployer.md)'s vulnerability response process usually involves the +following sequence of steps: + +```mermaid +flowchart LR +become_aware[Become
Aware] +prioritize_response[Prioritize
Response] +test_solution[Test the
Solution] +plan_deployment[Plan the
Deployment] +execute_plan[Execute
the Plan] + +become_aware --> prioritize_response +prioritize_response --> test_solution +test_solution --> plan_deployment +plan_deployment --> execute_plan +``` + +We cover each of these in more detail below. + +!!! note "Deployer Vulnerability Response Process in Context" + + This brief tutorial outlines the main steps of the deployer vulnerability response process. + Many of the steps here are covered in more detail (and from a more process-oriented rather than role-oriented perspective) + in the [Phases of CVD](../../topics/phases/index.md) section. + +!!! tip "Vulnerability Management" + + We're calling it the "deployer vulnerability response process" here, + but it's also known as "vulnerability management" or "patch management." + The process is the same, regardless of the name. + +{% include-markdown "../../_includes/_rmm_vm_wide.md" %} + +## Become Aware + +In order to take action, a deployer must know about the vulnerability +and have sufficient information to act on. Most often this information +originates from the product vendor. However, since not all vulnerability +reports are coordinated with the vendor for disclosure, vulnerability +information can arrive from other sources as well. + +!!! tip "What to Watch Out For" + + Deployers should be on the lookout for and pay attention to: + + - Vendor security notices + - Vendor customer support notices (not all vendors provide separate + security notices, nor are all vulnerabilities always explicitly + called out in update notes) + - Vulnerability and threat intelligence services + - Security discussions online including social media + - Mass media coverage of vulnerabilities + +## Prioritize Response + +Deployers have many responsibilities beyond deploying patches. As a +result, they need to prioritize their work and integrate patch +deployment into their normal operations cycle. That might mean testing, +scheduling out-of-band fixes, or planning for scheduled maintenance +windows. Just as vendors need to triage reports in order to prioritize +patch development appropriately, deployers must decide which patches and +mitigations to deploy and when to deploy them. The deployer's workload +often makes it difficult to patch all the things as quickly as they +would like. + +!!! tip "Prioritization Factors" + + Deployers should consider the following factors when prioritizing + their response: + + - The potential impact of the vulnerability on the organization + - The availability of an exploit + - The availability of a patch or mitigation + - The exposure of the affected systems to adversaries + - The potential for negative side effects from deploying the patch or + mitigation + +!!! ssvc "SSVC's Deployer Decision Model" + + Decision support tools like the [Stakeholder-Specific Vulnerability Categorization](https://certcc.github.io/SSVC) + (SSVC) framework can help deployers prioritize their vulnerability response actions. + SSVC provides an example [vulnerability prioritization decision model for deployers](https://certcc.github.io/SSVC/howto/deployer_tree/). + +## Test the Solution + +Testing prior to deployment is important if either of the following +conditions is true: + +- The system's availability and performance are critical +- Reverting a patch deployment gone bad is difficult + +In environments with efficient automated deployment and rollback +capabilities, it may not be as necessary to test as heavily. But that's +often an ideal scenario that few deployers find themselves in. + +!!! tip "Consider Staged Deployments" + + Staged deployments or rollouts can be a significant help. A staged deployment is one + where some portion of the affected systems are updated to confirm the fix + prior to wider rollout. Thus allowing deployers to balance patch deployment + with the risk of negative side effects. + +## Plan the Deployment + +Deployers have many options when it comes to planning to deploy a patch +or mitigation. Highly automated environments can dramatically shorten +the time required to complete these stages, but the functions described +here will usually still occur regardless of the deployer's automated +patching capability. + +!!! tip "Planning Tips" + + Planning for a patch deployment requires two major steps: + + 1. _Identify and enumerate system instances affected by the + vulnerability._ Vulnerability management tools can be used to scan + for affected systems and prioritize patch deployment. Information + about affected hosts helps to define the scale of the patching + effort required. + 2. _Set the deployment schedule._ If there are relatively few systems + under management and vulnerabilities are fairly rare, a + firstinfirst-out process might suffice. Larger enterprises often + have scheduled maintenance windows during which they can deploy most + patches. Alternatively, an organization might choose to push out a + patch outside of a scheduled maintenance window, especially in cases + where a vulnerability is being actively exploited or significant + harm is expected should the vulnerability remain unpatched until the + next maintenance window. Essentially the question boils down to + deploy now or defer to later? + +## Execute the Plan + +Obviously, it is important to actually carry out the deployment of the +mitigation or fix. Automated patch deployment tools can make this +process quite efficient. + +!!! tip "Monitor Deployment" + + Regardless of the degree of automation of patch + deployment, recurring or continuous monitoring for vulnerabilities can + help measure the success of the deployment effort. diff --git a/docs/tutorials/response_process/index.md b/docs/tutorials/response_process/index.md new file mode 100644 index 0000000..d972c19 --- /dev/null +++ b/docs/tutorials/response_process/index.md @@ -0,0 +1,146 @@ +# An Overview of the Coordination Process + + +Although the coordination process can be complex at times, +we can describe the general process in a few steps. The rest of this +guide goes into more detail on each of these steps and what else might happen along the way. + + +{% include-markdown "../../_includes/_what_is_coord.md" heading-offset=1 %} + +## Ideal Disclosure Process + +When a reporter is working directly with the vendor, the coordinated +disclosure process generally proceeds as follows: + +1. A reporter learns of a vulnerability (either directly as a user or + researcher, or indirectly from someone else) +2. Reporter finds vulnerable product's vendor, reports vulnerability + to vendor directly +3. Vendor analyzes the report, verifies information is correct, and + quickly acknowledges reporter + + ```mermaid + flowchart TD + reporter([Reporter]) + vendor([Vendor]) + reporter -->|1 learns of vul| reporter + reporter -->|2 reports vul| vendor + vendor -->|3 acknowledges| reporter + ``` + +4. Vendor provides information to reporter regarding patching the issue + and the timeframe until the patch is released publicly, reporter + agrees to publish on the same day +5. Reporter may test the patch before public release and provide + findings to vendor +6. Toward the end of the timeframe, before the patch is released, both + vendor and reporter draft security advisories and share with each + other for comment + + - If the vendor is a [CVE Numbering Authority](https://www.cve.org/ProgramOrganization/CNAs) (CNA), the vendor will assign a CVE ID + - Otherwise, the reporter or vendor may [request a CVE ID](https://www.cve.org/ReportRequest/ReportRequestForNonCNAs) from the CVE Program + + ```mermaid + flowchart TD + reporter([Reporter]) + vendor([Vendor]) + vendor -->|4 provides patch info| reporter + reporter -->|5 tests patch| vendor + vendor <-->|6 share draft
advisories| reporter + ``` + +7. The patch for the vulnerability may be released privately to affected + downstream vendors (customers/users of the vulnerable product) first +8. On an agreed-upon date, public security advisories are published + detailing the issue, and how to obtain the patch or mitigate the + issue + + - typically, the vendor will release an advisory simultaneously + with the reporter publishing an advisory on a blog, + social media, or mailing list, or via a conference presentation + +9. Once the vulnerability is public, (typically fairly quickly, especially if the + vendor is a CNA), the CVE record will be published to the [CVE List](https://www.cve.org/Downloads). +10. After the CVE record is published, the [National Vulnerability Database](https://nvd.nist.gov/) (NVD) + will publish its entry on the CVE ID, which provides extra information like vulnerability scoring. + + ```mermaid + flowchart TD + reporter([Reporter]) + vendor([Vendor]) + public([Public]) + cve([CVE List]) + nvd([NVD]) + vendor -->|7 release patch| public + vendor -->|8 publish advisory| public + reporter -->|8 publish advisory| public + vendor -->|9 CVE record| cve + cve -->|10 CVE record| nvd + cve -->|10 CVE record| public + nvd -->|11 NVD entry| public + + ``` + +End result: vulnerability is mitigated or addressed in some manner, +tracked with a CVE ID, and the public is informed through advisories +about how to obtain the mitigation. + +## Complications + +The above description is very idealized, while every coordinated +disclosure case is somewhat unique and may have special handling +requirements or constraints. The important idea is the word +*coordinated*: the formula presented above can be tweaked as much as +necessary as long as both parties are kept in the loop (coordinate!). + +In some simple cases, should a vendor become unresponsive, some +reporters will proceed to publishing a security advisory. This is +common, especially in cases where the vulnerability was initially +established but then no date is set for a patch release. This is fine to +do, but CERT/CC recommends to first reach out to the vendor with a draft +of your advisory before publishing. + +However, other cases can be more complex, such as reports that affect +multiple vendors, only some of which are responsive to the reporter. In +general, the CERT/CC is here to help with scenarios that go "off the +rails". This can include many different reasons, such as: + +- Reporter is new to coordination and disclosure and would like some + guidance on reporting and disclosing vulnerabilities +- Vendor is new to coordination and disclosure; the vendor may be + unreachable by the reporter, or the vendor may request guidance on + handling the report and establishing operations for future reports +- Multiple vendors are suspected of being affected, and the reporter + either has received no reply or is even unsure exactly who is + affected +- Vendor and Reporter disagree on the existence or severity of a + vulnerability; CERT/CC may be able to provide independent testing + and analysis + +In these cases you might contact the CERT/CC for assistance. + +{% include-markdown "../../_includes/_report_certcc.md" heading-offset=1 %} + +
+ +!!! question "I'm a reporter, what should I do next?" + + See the [Reporter Response Process](./reporter.md) for more information on what to do when you find a vulnerability. + +!!! question "I'm a vendor, what should I do next?" + + See the [Vendor Response Process](./vendor.md) for more information on what to do when you receive a report of a vulnerability. + +!!! question "I'm a deployer, what should I do next?" + + See the [Deployer Response Process](./deployer.md) for more information on what to do when you receive a report of a vulnerability. + +!!! tip "For More Information" + + We have a lot more to say about the coordination process. + For more on the general topic, see the [How-To](../../howto/index.md) section of this site. + For specific advice on complications that can arise during the coordination process, + see the [Troubleshooting CVD](../../howto/coordination/cvd_recipes.md) section of this site. + +
diff --git a/docs/tutorials/response_process/reporter.md b/docs/tutorials/response_process/reporter.md new file mode 100644 index 0000000..c713b90 --- /dev/null +++ b/docs/tutorials/response_process/reporter.md @@ -0,0 +1,145 @@ +# Reporter Vulnerability Response Process + +If you've found a vulnerability and intend to report it, +you're about to become a vulnerability [reporter](../../topics/roles/finder.md). +While this entire guide is written with you in mind, you might need to know +where to start. That's what this page is for. + +!!! question "Who is a Vulnerability Reporter?" + + We generally refer to anyone that contacts us or a vendor to + report a vulnerability in a product, service, or system + as a + _vulnerability reporter_, or usually simply [*reporter*](../../topics/roles/finder.md). + This is to distinguish from the fact that the reporter is not always the + original person that discovered the vulnerability, or in some cases, + that several people discovered the same vulnerability simultaneously. + Another term is _finder_, as in the person that finds a vulnerability + and reports it, but in terms of coordination, it's the reporter role + that is interacting with the CVD process. + +## Step 0: Find a Vulnerability + +Since you're here, you've probably already done this step. + +## Step 1: Decide What to Do + +The finder of a vulnerability has several options for what to do next. + +```mermaid +flowchart TD + finder([Finder]) + decide{ } + null([Nobody]) + public([Public]) + subgraph cvd[CVD] + vendor([Vendor]) + coordinator([Coordinator]) + end + finder -->|What to do?| decide + decide -->|stay quiet| null + decide -->|report to| vendor + decide -->|report to| coordinator + decide -->|publish| public +``` + +We'll cover the coordinated disclosure options in a moment, but first let's pause to examine the non-CVD options. + +
+!!! warning "Do Nothing?" + + It is possible to find a vulnerability and do nothing about it. This is + not usually recommended, as it leaves the vulnerability unaddressed and + potentially exploitable by others. But it is a choice that is available + to the finder. + +!!! warning "Go Public?" + + It is also possible to find a vulnerability and publish it immediately. + This is sometimes called _full disclosure_. This is also not usually + recommended, as it can lead to exploitation of the vulnerability before + a fix is available. But it is a choice that is available to the finder. +
+ +## Step 2: Prepare a Report + +If you've decided to report the vulnerability, you'll need to prepare a report. +The best advice is to document your vulnerability well. This typically +means providing: + +- the exact software version or model version affected +- a description of how the vulnerability was discovered (including + what tools were used) or what you were doing when you encountered + the vulnerability +- a proof of concept (PoC) code or instructions demonstrating how the + vulnerability may be exploited; ideally, a suggested patch for the + issue may be included +- description of the impact of the vulnerability and attack scenario + (for example, see BugCrowd's [write up](https://forum.bugcrowd.com/t/writing-a-bug-report-attack-scenario-and-impact-are-key/640) on the topic) +- any time constraints (for example, give a date of publication or + presentation at a conference if you know) + +!!! tip "Providing Useful Information" + + See [Providing Useful Reports](../../howto/initiation/useful_reports.md) for more information on what makes a report useful. + +{% include-markdown "../../_includes/_eff_advice.md" heading-offset=2 %} + +## Step 3a: Engage the Vendor + +We usually recommend that a reporter first try reporting the +vulnerability directly to the [*vendor*](../../topics/roles/vendor.md) or maintainer of the software in +question. + +The vendor or maintainer of the software is often easy to contact and +responsive to security concerns. Simply send your report to the vendor +and ask what timeline for a fix is needed. + +!!! tip "Finding Vendor Contacts" + + See [Finding Vendor Contacts](../../howto/initiation/find_vendor_contact.md) for more information on finding the right contact at a vendor. + +## Step 3b: Engage a Coordinator + +There are several reasons for not coordinating directly with the vendor. +If any of the following conditions are true, you might consider reaching +out to a [coordinator](../../topics/roles/coordinator.md) like the CERT/CC +for assistance in coordinating or publishing your +case if one or more of the following conditions are true: + +- the vendor or maintainer does not reply in a reasonable time + frame (typically about two weeks) +- the vendor was initially responsive, but then stopped responding + (typically about two weeks of silence) +- the vendor has fixed a critical issue, but did not clearly + document the fix in a security advisory, news article, or changelog +- the vulnerability affects multiple vendors and would be difficult + for an individual reporter to coordinate alone +- the vulnerability is extremely serious and could cause extensive + nation-wide or world-wide damage (for example, problems with + internet infrastructure protocols like DNS and NTP) +- you wish to remain anonymous (if so, you may also wish to use a + pseudonym and contact the coordinator with a free *throw-away* email + account) + +!!! tip "More reasons to engage a Coordinator" + + We have collected a variety of other [Reasons to Engage a Coordinator](../../howto/coordination/coordinator_reasons.md) + in the [How To](../../howto/index.md) section of this site. + +!!! tip "Requesting Coordination Assistance from the CERT/CC" + + To request assistance, please fill out our [Vulnerability Reporting Form](https://kb.cert.org/vuls/report/) + (VRF) + + For more information about working with the CERT/CC, you may wish to + read the following resources that describe our typical process: + + - [CERT/CC Disclosure Policy](../../reference/certcc_disclosure_policy.md) -- we typically disclose vulnerability information + in a publication within 45 days of initial vendor contact attempt + - [Guidelines for Requesting Coordination Assistance](../coord_certcc/reporter.md) - + some tips for submitting a coordination assistance request to CERT/CC + +## Step 4: Coordinate + +[CVD How-To](../../howto/index.md) leads to more detailed information and advice about the CVD process. diff --git a/docs/tutorials/response_process/vendor.md b/docs/tutorials/response_process/vendor.md new file mode 100644 index 0000000..a0bfab9 --- /dev/null +++ b/docs/tutorials/response_process/vendor.md @@ -0,0 +1,198 @@ +# Vendor Vulnerability Response Process + +{% include-markdown "../../_includes/_who_is_a_vendor.md" heading-indent=1 %} + +If you are producing products that rely on computers and software, you +need to begin taking action now to have appropriate processes and +response. In order to effectively mitigate the impact of vulnerabilities in their +products and services, [vendors](../../topics/roles/vendor.md) must be able to perform the following +specific tasks: + +```mermaid +flowchart LR + receive[Receive
Reports] + validate[Validate
Reports] + prioritize[Prioritize] + analyze[Analyze &
Test Claims] + fix[Fix
the Problem] + distribute[Distribute
Patch] + publish[Publish
Document] + improve[Improve Internal
Development Process] + + receive --> validate + validate --> prioritize + prioritize --> analyze + analyze --> fix + fix --> distribute + distribute --> publish + fix --> improve + analyze --> improve + improve --> improve +``` + +!!! note "Vendor Vulnerability Response Process in Context" + + This brief tutorial outlines the main steps of the vendor vulnerability response process. + Many of the steps here are covered in more detail (and from a more process-oriented rather than role-oriented perspective) + in the [Phases of CVD](../../topics/phases/index.md) section. + +!!! info "ISO/IEC Standards for Vulnerability Disclosure and Handling Processes" + + The ISO/IEC standards [29147 _Vulnerability disclosure_](https://www.iso.org/standard/72311.html) and + [30111 _Vulnerability handling processes_](https://www.iso.org/standard/69725.html) + offer specific models for external- + and internal-facing vendor vulnerability response practices. Readers are + encouraged to review and apply those standards to their operational + vulnerability response practice. ISO/IEC 29147 describes an + outward-facing CVD process. ISO/IEC 30111 addresses the internal + processes associated with vendor vulnerability response. + +## Receive Reports + +The first step in the vendor vulnerability response process is to receive +vulnerability reports. Reports can come from a variety of sources, +including internal testing, customer reports, third-party researchers, +and public disclosure. + +!!! tip "Have a Mechanism to Receive Reports from All Sources" + + Vendors should have a mechanism in place to + receive reports from all of these sources. This mechanism should be + secure, reliable, and easy to use. It should also be well-publicized so + that reporters know how to submit reports. + +## Validate Reports + +Validation of vulnerability reports is the next step in the vendor +vulnerability response process. The goal of this step is to determine +whether the report is valid and whether the reported issue is indeed a +vulnerability. + +!!! tip "Validation is Surface-Level" + + Validation is a surface-level process. It is not the same as + understanding the vulnerability in detail. The goal of validation is to determine + whether the report is sufficient to take further action on and whether the reported issue is indeed a + vulnerability. Understanding the vulnerability comes later in the process. + +## Prioritize + +Once a vulnerability report has been validated, the vendor must prioritize +the response. This is a critical step, as it is unlikely that the vendor +will be able to fix all reported vulnerabilities at once. Prioritization +is based on a variety of factors, including the severity of the +vulnerability, the likelihood of exploitation, and the potential impact of +exploitation. + +!!! tip "Prioritization Criteria" + + The criteria for prioritization should be well-documented and + consistently applied. This will help ensure that the vendor's + vulnerability response process is transparent and fair. + +!!! ssvc "SSVC and risk-based prioritization" + + The [Stakeholder-Specific Vulnerability Categorization](https://certcc.github.io/SSVC) + (SSVC) framework provides decision support tools for vendors to use in + prioritizing vulnerabilities. Specifically, we have developed a + [Supplier Prioritization Decision Model](https://certcc.github.io/SSVC/howto/supplier_tree/) + that can help vendors prioritize their vulnerability response actions. + +## Analyze & Test Claims + +Isolating the root cause of a vulnerability and developing a fix can be +complex. The vendor must analyze the vulnerability to understand how it +can be exploited and how it can be fixed. This often involves testing the +vulnerability to ensure that the fix is effective and does not introduce +new vulnerabilities. + +!!! tip "Understanding the Vulnerability" + + Understanding the vulnerability is critical to developing an effective + fix. Vendors often need to isolate the root cause of the vulnerability to + ensure that their fix is comprehensive and effective. + +## Fix the Problem + +Once the vulnerability has been analyzed and understood well enough for the vendor to know how to fix it, +it is time to develop and test the fix. This can be as simple as a one-line change or a complex architectural refactoring. + +!!! warning "Do not just fix the proof-of-concept" + + Some vendors will only fix the behavior specifically triggered by the proof-of-concept + exploit provided by the reporter. This is a mistake, because it may leave open other + ways to trigger the same vulnerability. The vendor should fix the root cause of the + vulnerability, not just the specific proof-of-concept exploit. + +## Distribute Patch + +A fix is not effective until it is deployed to all vulnerable systems. Some vendors +have mechanisms in place to automatically deploy patches to their customers. Others rely on +customers to manually apply patches. In either case, the vendor should ensure that the patch +is made available to all affected systems. + +!!! tip "Automated Patch Deployment" + + Automated patch deployment can be an effective way to ensure that patches are + deployed quickly and consistently. This can help reduce the window of opportunity for + attackers to exploit the vulnerability. + +## Publish Document + +Many [deployers](../../topics/roles/deployer.md) rely on the vendor to provide clear and +accurate information about the vulnerability and the fix in order to know that they need to take action. +This information should be made available to the public as soon as the patch is available. + +## Process Improvement + +Having a mechanism to receive and track the disposition of vulnerability +reports is an important first step in establishing a vendor's +vulnerability response capability. But it should not stop there; vendors +should strive for continuous improvement of their software development +process. +Improving the development process can reduce the number of +vulnerabilities in future products. Vendors can establish a feedback +loop by performing a root cause analysis of vulnerabilities reported. +Lessons learned can then inform modifications to the development +process. + +!!! tip "Ways Vulnerability Response Feeds Back into the Development Lifecycle" + Some of the ways vulnerability response can feed back into the + development lifecycle include the following: + + - **Root cause analysis** -- to identify common causes and learn how + to reduce future introduction of similar vulnerabilities. Questions + to ask include the following: How did this vulnerability make it + into the released product without being detected? How could it have + been found and fixed earlier, before release? How might the + vulnerability have been avoided entirely? + - **Automated testing** -- to find vulnerabilities sooner, ideally + before release. Continuous integration (CI) systems and DevOps + practices provide excellent opportunities to incorporate automated + security testing. For example, a CI server could initiate a fuzzing + campaign on each nightly build of a product. An automated release + process might require that code pass all static analysis tests with + no significant findings before proceeding. + - **Threat modeling** -- to identify high**-**risk portions of a + product earlier in the development process so potential + vulnerabilities can be found and addressed at design time, before + they are even implemented. + +!!! tip "Evaluating the Vendor Security Response Process" + + It is a mistake to evaluate a product favorably based solely on its + having a low number of publicly known vulnerabilities. In fact, the + known vulnerability count in a product is usually not indicative of the + quality of a product. There are many reasons a product may have few + public vulnerability reports: these include (1) the vendor might lack + proper CVD capabilities or have a history of threatening legal action + against finders and reporters if they publish vulnerability reports, or + (2) the product's prevalence or niche may be too small to warrant + finder attention. + + Instead, we have found that a vendor's CVD capability and vulnerability + response process maturity is often a more important indicator of its + commitment to quality than its vulnerability counts alone. Development + practices, as human processes, inevitably fail. Vendors that acknowledge + this fact and create a good CVD practice are well positioned to + compensate for this inevitability. diff --git a/docs/tutorials/terminology.md b/docs/tutorials/terminology.md new file mode 100644 index 0000000..206d77c --- /dev/null +++ b/docs/tutorials/terminology.md @@ -0,0 +1,18 @@ +# CVD Terminology + +We need to agree on what we're talking about when we talk about CVD. +In this section, we define the terms that are used throughout the remainder of +this site. + +
+ +- :material-alert: [Vulnerability](./terms/vulnerability.md) +- :material-fire-alert: [Exploits, Malware, and Incidents](./terms/exp_mw_inc.md) +- :fontawesome-solid-cubes-stacked: [Products and Instances](./terms/products_instances.md) +- :material-fire-truck: [Vulnerability Response](./terms/vulnerability_response.md) +- :material-magnify: [Vulnerability Discovery](./terms/vulnerability_discovery.md) +- :material-cube-scan: [Vulnerability Scanning](./terms/vulnerability_scanning.md) +- :control_knobs: [Vulnerability Management](./terms/vulnerability_management.md) +- :material-camera-control: [Coordinated Vulnerability Disclosure](./terms/cvd.md) + +
diff --git a/docs/tutorials/terms/_disco_scan.md b/docs/tutorials/terms/_disco_scan.md new file mode 100644 index 0000000..d90bfb7 --- /dev/null +++ b/docs/tutorials/terms/_disco_scan.md @@ -0,0 +1,7 @@ +!!! tip "Vulnerability Discovery vs. Vulnerability Scanning" + + [*Vulnerability Discovery*](./vulnerability_discovery.md) is the process of finding new vulnerabilities in software or hardware. + This is distinct from [*Vulnerability Scanning*](./vulnerability_scanning.md), which is the process of using automated tools to find _known_ + vulnerabilities in software or hardware. + *Vulnerability scanning* is a useful tool for finding known vulnerabilities in a system as part of a + [*vulnerability management*](./vulnerability_management.md) program, but it is not a substitute for _vulnerability discovery_. diff --git a/docs/tutorials/terms/cvd.md b/docs/tutorials/terms/cvd.md new file mode 100644 index 0000000..f772d01 --- /dev/null +++ b/docs/tutorials/terms/cvd.md @@ -0,0 +1,123 @@ +# Coordinated Vulnerability Disclosure + +!!! abstract "Coordinated Vulnerability Disclosure" + + Coordinated Vulnerability Disclosure is the process of gathering + information from vulnerability finders, coordinating the sharing of that + information between relevant stakeholders, and disclosing the existence + of software vulnerabilities and their mitigations to various + stakeholders, including the public. + +CVD is an important aspect of any successful [Vulnerability Response](vulnerability_response.md) (VR) process. +CVD inputs are [vulnerability reports](../../topics/phases/reporting.md) arising from [vulnerability discovery](vulnerability_discovery.md) practices. +CVD outputs for [product](products_instances.md) vulnerabilities (software or hardware) usually include fixes or mitigation advice as well +as [vulnerability report documents](../../topics/phases/publishing.md) or vulnerability database records, typically with some formal identifier +(e.g., +[CVE](https://www.cve.org), +[VU#](https://www.kb.cert.org/vuls), +[BID](https://en.wikipedia.org/wiki/Bugtraq)). + +!!! tip "CVD is not exclusive to software product vulnerabilities" + + Many operational ([instance](products_instances.md)) vulnerabilities such as router misconfigurations, website + vulnerabilities, or cloud service problems can be fixed in situ by the [vendor](../../topics/roles/vendor.md), + who as the operator of the service or instance, also acts as the [deployer](../../topics/roles/deployer.md). + Althouth it is less common for these types of vulnerabilities to be disclosed publicly, they can + still be addressed through a CVD process. + Often these vulnerabilities are reported to the deployer directly, possibly as part of a Vulnerability Disclosure Program (VDP). + +[ISO/IEC 29147](https://www.iso.org/standard/72311.html) defines Vulnerability Disclosure as follows: + +!!! quote "ISO/IEC 29147:2014 Information technology—Security techniques—Vulnerability disclosure" + + Vulnerability disclosure is a process through which vendors and + vulnerability finders may work cooperatively in finding solutions that + reduce the risks associated with a vulnerability. It encompasses + actions such as reporting, coordinating, and publishing information + about a vulnerability and its resolution. + + The goals of vulnerability disclosure include the following: a) + ensuring that identified vulnerabilities are addressed; b) minimizing + the risk from vulnerabilities; c) providing users with sufficient + information to evaluate risks from vulnerabilities to their systems; + +The stakeholders—in other words, the people who care about the +existence of a vulnerability—vary on a case by case basis, but +typically include those below: + +- the [reporter](../../topics/roles/finder.md) or [finder](../../topics/roles/finder.md) of the vulnerability (often an independent + security researcher) +- the [vendor](../../topics/roles/vendor.md) (developer) of the component that contains the + vulnerability (See also *originating vendor* in [MPCVD](../../howto/coordination/mpcvd.md)) +- [vendors](../../topics/roles/vendor.md) that utilize the component containing the vulnerability in + their own products (See also *downstream vendors* in [MPCVD](../../howto/coordination/mpcvd.md)) +- [coordinators](../../topics/roles/coordinator.md), vulnerability databases, or other organizations that + specialize in incident response and vulnerability handling +- [deployers](../../topics/roles/deployer.md) and the general public / consumers who purchase and use products containing the vulnerable component + +Disclosure, in turn, is the process by which information about a +vulnerability (ideally with advice for mitigating or fixing it) is +released to consumers of the product, and more generally, the public at +large. *There is no single "right" way to do this.* Sometimes, +vulnerability information is disclosed in a blog post by the finder of +the vulnerability, or emailed to a security mailing list. Sometimes the +vendor issues a security advisory to its customers or to the public. At +the CERT/CC, we publish [Vulnerability Notes](https://www.kb.cert.org/vuls) on our website, often in +parallel with other parties (i.e., the finder of the vulnerability +and/or the vendor of the vulnerable product). + +!!! tip "Opinions Differ on Disclosure" + + A lack of agreement within the security community persists + on whether, and under what conditions, vulnerability information should + be disclosed to vendors, other stakeholders, and the public. + Different people sometimes hold strongly differing opinions + about the disclosure of software vulnerabilities. These differences tend + to center on the timing of a vulnerability report's release, the type + and degree of details included, and the audience to whom the report is + provided. + + As a result, the character of information in a vulnerability report can + vary greatly. Some reports only warn of a general vulnerability in a + specific product. Others are more detailed and provide actual examples + of how to attack the flaw (these examples are called "proof of concept + code," often shortened to "PoC"). + +It is worth reiterating that disclosure is not a [singular event](../cvd_is_a_process.md) even for +a single vulnerability. For more on the different phases of the CVD process, +see [Phases](../../topics/phases/index.md). + +!!! question "Who is *Responsible* Here?" + + You may be familiar with the term [*responsible disclosure*](https://datatracker.ietf.org/doc/draft-christey-wysopal-vuln-disclosure/) + and + wonder how it's different from CVD. The history of *responsible + disclosure* makes for a long story best told over adult beverages at a + hotel bar during a security conference, so we won't go into it here. + Without belaboring the topic, the sticking point comes down to the fact + that what constitutes _responsible_ behavior is a matter of opinion + that is always framed within the values of whoever is using the term. + + The vendors cry, "Disclosing a vulnerability without an available patch + is not responsible!" "Not fixing this vulnerability quicker is not + responsible!" the finders retort. Meanwhile, the deployer asks, + "Who's responsible for fixing this?" while knowing the answer all too + well. + + ```mermaid + sequenceDiagram + actor F as Finder + actor V as Vendor + actor D as Deployer + + V ->> F: Disclosure
without a patch
is irresponsible! + F ->> V: Not fixing
this vulnerability quicker
is irresponsible! + D ->> D: Who's responsible
for fixing this? + ``` + + Because of the inherent value judgement and lack of agreement on + its definition, the CERT/CC, along with [numerous](https://www.microsoft.com/en-us/msrc/cvd) + [other](https://www.cisa.gov/coordinated-vulnerability-disclosure-process) + [organizations](https://www.enisa.europa.eu/news/enisa-news/coordinated-vulnerability-disclosure-policies-in-the-eu), + advocates for the use of the term *Coordinated Vulnerability Disclosure + (CVD)* to reduce misunderstanding and promote cooperation. diff --git a/docs/tutorials/terms/exp_mw_inc.md b/docs/tutorials/terms/exp_mw_inc.md new file mode 100644 index 0000000..42dda20 --- /dev/null +++ b/docs/tutorials/terms/exp_mw_inc.md @@ -0,0 +1,20 @@ +# Exploits, Malware, and Incidents + +Any discussion of [*vulnerabilities*](vulnerability.md) would be incomplete without also discussing *exploits*, *malware*, and *incidents*. +These terms are closely related to vulnerabilities, but they are not the same thing. + +!!! abstract "Exploit" + + An *exploit* is software that uses a [vulnerability](./vulnerability.md) to achieve some effect. + Sometimes the effect is as simple as demonstrating the existence of the vulnerability. + Other times it plays a role in enabling adversaries to attack systems. + +!!! abstract "Malware" + + *Malware* is software used by adversaries to compromise the security of a system or systems. + Some malware involves exploits to achieve its goals, but not all malware involves exploits. + +!!! abstract "Incident" + + An *incident* is a violation or an attempted violation of a security policy, and may involve malware, exploits, or + vulnerabilities (or none of these!) diff --git a/docs/tutorials/terms/products_instances.md b/docs/tutorials/terms/products_instances.md new file mode 100644 index 0000000..7ed44ca --- /dev/null +++ b/docs/tutorials/terms/products_instances.md @@ -0,0 +1,63 @@ +# Products and Instances + +In talking about things that have vulnerabilities, we try to maintain a +clear distinction between a *product* being vulnerable, and an *instance +of a product* being vulnerable. + +!!! abstract "Product" + + A *product* is a software or hardware system that is released by a + vendor or manufacturer. A product is a general concept that can be + instantiated in many different ways. + +!!! abstract "Instance" + + An *instance* is a specific deployment of a product. An instance is + a concrete realization of a product that is running on a specific + system. + +One way to think about this distinction is to consider the difference between +the make and model of a car (the product) and a *specific* car (the instance). +In that context, the *product* is actually a category of cars that share certain characteristics, +components, and features. A specific car that belongs to that category would be considered +an *instance*. + +!!! example "Product vs. Instance" + + Consider a vulnerability in Windows 11. Windows 11 is a _product_ + that is released by Microsoft. If there is a vulnerability in + Windows 11, then the _product_ Windows 11 is vulnerable, as are all + _instances_ of Windows 11 that have not been patched against the + vulnerability. + + Now consider a specific server that is running Windows 11. This server is an + _instance_ of the _product_ Windows 11. If the server has been configured + in such a way that it is vulnerable to attack (e.g., it has not been + patched against a vulnerability in the _product_ Windows 11), + then the _instance_ of Windows 11 is vulnerable. + +!!! tip "Why the Distinction Matters" + + Vulnerabilities affecting products may not always affect every instance + of a product; for example, a vulnerability may require a special + configuration or setup to be exploited, so any instance not in that + configuration state would actually be unaffected by the vulnerability, + despite the product at-large being vulnerable. + + Alternately, it is possible for an instance to be vulnerable even if the + product is not. For example, a vulnerability may be introduced by a + misconfiguration such as an insecure permission setting. In this case, + the product itself would not be considered to have a vulnerability, but the instance + would. + +This distinction becomes important when one is talking about the +practices associated with [Vulnerability Management](vulnerability_management.md) +(VM)—namely +[*vulnerability scanning*](vulnerability_scanning.md)—in contrast to CVD and +[*vulnerability discovery*](vulnerability_discovery.md). + +VM entails the identification of *instances* of a *product* +on which action must be taken to remediate known vulnerabilities in the +product. VM is concerned with the eradication of the *instances* of known +vulnerabilities in deployed systems, whereas CVD is concerned with the +repair of vulnerabilities at the *product* level. diff --git a/docs/tutorials/terms/vulnerability.md b/docs/tutorials/terms/vulnerability.md new file mode 100644 index 0000000..db2f142 --- /dev/null +++ b/docs/tutorials/terms/vulnerability.md @@ -0,0 +1,61 @@ +# Vulnerability + +!!! abstract "Vulnerability" + + A *vulnerability* is a set of conditions or behaviors that allows the + violation of an explicit or implicit security policy. + +Vulnerabilities +can be caused by software defects, configuration or design decisions, +unexpected interactions between systems, or environmental changes. +Successful exploitation of a vulnerability has technical and risk +impacts. Vulnerabilities can arise in information processing systems as +early as the design phase and as late as system deployment. + +!!! quote "*Vulnerability* in the NIST Glossary" + + NIST offers the following [definitions](https://csrc.nist.gov/glossary/term/vulnerability) of vulnerability: + + 1. "Weakness in an information system, system security procedures, + internal controls, or implementation that could be exploited or + triggered by a threat source" + 1. "A weakness in a system, application, or network that is subject to + exploitation or misuse" + 2. "Weakness in an information system, system security procedures, + internal controls, or implementation that could be exploited by a + threat source" + +Those familiar with the [CERT Resiliency Management Model](https://insights.sei.cmu.edu/library/cert-resilience-management-model-cert-rmm-collection/) +(RMM) may be accustomed to the more general definition of vulnerability in the +[Vulnerability Analysis and Resolution](https://insights.sei.cmu.edu/library/vulnerability-analysis-and-resolution-var-cert-rmm-process-area/) +(VAR) process area: + +!!! quote "*Vulnerability* in the CERT RMM" + + A vulnerability is the susceptibility of an asset and associated service to disruption. + +A summary of the VAR process area of the CERT RMM is provided in our discussion +of [Vulnerability Management](vulnerability_management.md). + +While vulnerabilities can be found in many assets belonging to an +organization—people, information, technology, and facilities—in this +documentation we primarily focus on vulnerabilities in software or +software-centric products and to a lesser degree services built on +software-dependent products. +While precisely defining vulnerability can +be difficult, for our purpose a vulnerability may be thought of as an +undesirable, exploitable, and likely unintended feature of software or +hardware components that allows an attacker to perform actions that +wouldn't otherwise be available to them. The impact of such +vulnerabilities can vary greatly, from being able to access someone's +private data, to taking control of a computer, to causing physical +damage and bodily injury. + +!!! question "Why does CERT shorten *vulnerability* to *vul* instead of *vuln*?" + + Lots of folks ask us this question. The answer is simple: Tradition. + We've been calling them _vuls_ (no _n_) since at least 1993, and we have the email archives to prove it. + Considering how many times we've had to type it, we figure we've saved ourselves approximately a + gazillion keystrokes over the years. + At this point, it's become a [shibboleth](https://en.wikipedia.org/wiki/Shibboleth) for CERT/CC staff and alumni. + You can start using it too, and instantly make your CVD practice _up to_ 25% more efficient! diff --git a/docs/tutorials/terms/vulnerability_discovery.md b/docs/tutorials/terms/vulnerability_discovery.md new file mode 100644 index 0000000..6184dbb --- /dev/null +++ b/docs/tutorials/terms/vulnerability_discovery.md @@ -0,0 +1,22 @@ +# Vulnerability Discovery + +!!! abstract "Vulnerability Discovery" + + Vulnerability Discovery refers to the process of searching for and + finding previously unknown vulnerabilities in information processing systems. + +Vulnerability discovery can take many forms, from specifically targeted +software testing to simple use of a system by a security-aware +individual who notices some feature that seems out of place. In order +for that discovery to be relevant to our discussion, it must result in a +vulnerability report. Most discussions about vulnerability disclosure +are referring to the handling of reports of newly discovered +vulnerabilities in products for which no patch exists + +!!! question "So you mean *zero days*?" + + Colloquially, yes. But for a more nuanced discussion regarding why we're eschewing the term *zero-day + vulnerability* here, see our blog post + [_Like Nailing Jelly to the Wall: Difficulties in Defining "Zero-Day Exploit"_](https://insights.sei.cmu.edu/blog/like-nailing-jelly-to-the-wall-difficulties-in-defining-zero-day-exploit/) + +{% include-markdown "./_disco_scan.md" heading-offset=1 %} diff --git a/docs/tutorials/terms/vulnerability_management.md b/docs/tutorials/terms/vulnerability_management.md new file mode 100644 index 0000000..81e3011 --- /dev/null +++ b/docs/tutorials/terms/vulnerability_management.md @@ -0,0 +1,19 @@ +# Vulnerability Management (VM) + +!!! abstract "Vulnerability Management (VM)" + + _Vulnerability Management_ is the common term for tasks such as + vulnerability scanning, patch testing, and deployment. + +VM practices nearly always deal with the output of CVD practices, not the inputs. +VM practices focus on the positive action of identifying specific systems +affected by known (post-disclosure) vulnerabilities and reducing the +risks they pose through the application of mitigations or remediation +such as patches or configuration changes. +In other words, VM entails the identification of +[*instances*](./products_instances.md) of a [*product*](./products_instances.md) +on which action must be taken to mitigate or remediate known vulnerabilities in the +product. + +{% include-markdown "../../_includes/_rmm_vm_wide.md" %} +{% include-markdown "../../_includes/_NIST_SP_800-40.md" %} diff --git a/docs/tutorials/terms/vulnerability_response.md b/docs/tutorials/terms/vulnerability_response.md new file mode 100644 index 0000000..cc3a7c7 --- /dev/null +++ b/docs/tutorials/terms/vulnerability_response.md @@ -0,0 +1,44 @@ +# Vulnerability Response (VR) + +!!! abstract "Vulnerabilty Response (VR)" + + Vulnerability Response is the overall set of processes and + practices that deal with the existence of vulnerabilities in systems. + VR encompasses everything from reducing the introduction of vulnerabilities + as part of a Secure Development Lifecycle (SDL) through the remediation + of deployed vulnerabilities via patch deployment. + +!!! info inline end "Resources" + + Below are a few resources for further reading on these topics: + + - [Threat Modeling](https://shostack.org/books/threat-modeling-book) is Adam Shostack's book on the subject. + - [SEI CERT Coding Standards](https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards) is a collection of coding standards from the CERT Division of the Software Engineering Institute. + - [Cybersecurity Engineering Research: Security Engineering Risk Analysis (SERA) Collection](https://insights.sei.cmu.edu/library/cybersecurity-engineering-research-security-engineering-risk-analysis-sera-collection/) is a collection of resources on the topic from the CERT Division of the Software Engineering Institute. + +Vulnerability response in the design and development phases often takes +the form of practices such as Threat Modeling, Secure Coding, and Software +Engineering Risk Analysis. + +However, such practices seem unlikely to ever completely eliminate vulnerabilities +from being introduced into released software and deployed systems. For +those vulnerabilities that do escape detection by these early lifecycle +practices, it remains necessary to plan for their eventual discovery and +disclosure. + +The goals of vulnerability response include the following: + +- Limit attacker advantage over defenders. +- Reduce the population of vulnerable product instances as quickly as + possible. +- Reduce the impact of attacks against vulnerable systems. + +!!! tip "Incident Response vs. Vulnerability Response" + + Sometimes the term _Incident Response_ is used synonymously with + _Vulnerability Response_. These two concepts are related, but different; + _Vulnerability Response_ specifically indicates responding to reports of + product vulnerabilities, usually via the CVD process, whereas _Incident + Response_ is more general and can also include other security events such + as network intrusions. We will generally stick to the _Vulnerability + Response_ terminology since this work is specifically about CVD. diff --git a/docs/tutorials/terms/vulnerability_scanning.md b/docs/tutorials/terms/vulnerability_scanning.md new file mode 100644 index 0000000..586e808 --- /dev/null +++ b/docs/tutorials/terms/vulnerability_scanning.md @@ -0,0 +1,11 @@ +# Vulnerability Scanning + +!!! abstract "Vulnerability Scanning" + + *Vulnerability scanning* is the practice of using automated tools to identify known vulnerabilities in systems, applications, and networks. + +Scanning tools compare the configuration of a system to a database of known vulnerabilities and generate a report of the findings. +Scanning tools can be used to identify vulnerabilities in a wide range of systems, including operating systems, applications, and network devices. +The results of a vulnerability scan can be used to prioritize remediation efforts and reduce the risk of exploitation by adversaries. + +{% include-markdown "./_disco_scan.md" heading-offset=1 %} diff --git a/docs/why_this_guide.md b/docs/why_this_guide.md new file mode 100644 index 0000000..817beb2 --- /dev/null +++ b/docs/why_this_guide.md @@ -0,0 +1,238 @@ +# Why We Wrote This Guide + +Software and software-based products have vulnerabilities. Left +unaddressed, those vulnerabilities expose to risk the systems on which +they are deployed and the people who depend on them. In order for +vulnerable systems to be fixed, those vulnerabilities must first be +found. Once found, the vulnerable code must be patched or configurations +must be modified. Patches must be distributed and deployed. Coordinated +Vulnerability Disclosure (CVD) is a process intended to ensure that +these steps occur in a way that minimizes the harm to society posed by +vulnerable products. This guide provides an introduction to the key +concepts, principles, and roles necessary to establish a successful CVD +process. It also provides insights into how CVD can go awry and how to +respond when it does so. + +!!! tip "The Importance of Coordinated Vulnerability Disclosure" + + In a nutshell, CVD can be thought of as an iterative process that begins + with someone finding a vulnerability, then repeatedly asking "what + should I do with this information?" and "who else should I tell?" until + the answers are "nothing," and "no one." But different parties have + different perspectives and opinions on how those questions should be + answered. These differences are what led us to write this guide. + +!!! info "CVD at the CERT Coordination Center" + + The CERT Coordination Center has been coordinating the disclosure of + vulnerability reports since its inception in 1988. Although both our + organization and the Internet have grown and changed in the intervening + decades, many of the charges of our initial charter remain central to + our mission: to facilitate communication among experts working to solve + security problems; to serve as a central point for identifying and + correcting vulnerabilities in computer systems; to maintain close ties + with research activities and conduct research to improve the security of + existing systems; and to serve as a model for other incident response + organizations. + +## Growing Complexity of the Software Supply Chain + +If we have learned anything in nearly three decades of coordinating +vulnerability disclosures at the CERT/CC, it is that there is no single +right answer to many of the questions and controversies surrounding the +disclosure of information about software and system vulnerabilities. + +
+ +!!! abstract "Traditional Computing" + + In the traditional computing arena (e.g., dominated by laptops, desktops, servers, and + locally-run software), most vendors and researchers have + settled into a reasonable rhythm of allowing the vendor some time to fix + vulnerabilities prior to publishing a vulnerability report more widely. + +!!! abstract "Mobile Computing" + + Mobile computing (e.g., Smartphones, tablets, and other mobile devices) has + introduced new challenges to the vulnerability coordination process. + For example, we first started thinking about _supply chain viscosity_ in the context + of mobile computing, where the complexity of the ecosystem made it + difficult to establish consistent practices for reporting and remediating + vulnerabilities. + +!!! abstract "Web Sites and Applications" + + Web sites and applications are another area where the ability to fix and deploy patches has improved. + Many web sites and applications are now built using continuous integration and continuous deployment (CI/CD) pipelines, + which can allow for rapid deployment of fixes to vulnerabilities. + However, the ability to deploy patches quickly is not universal, and there are still many web sites and + applications that are not built using CI/CD pipelines. + +!!! abstract "Cloud Computing and Software as a Service" + + As things have progressed, we've found that while there can still be challenges + with reporting vulnerabilities to vendors, in most cases + software as a service (SAAS) providers, + and software distributed through app stores can often fix and deploy patches to most customers quickly. + Traditional software vendors have also improved their ability to fix and deploy patches, + although there is often a lag between the time a patch is available and the time it is deployed to all customers + due to the need for the deployer to take action to install the fix. + +!!! abstract "Internet of Things" + + On the opposite end of the spectrum, we find many Internet of Things (IoT) and + embedded device vendors for whom fixing a vulnerability might require a + firmware upgrade or even physical replacement of affected devices, + neither of which can be expected to happen quickly (if at all). + There is far less consistency in the ability of IoT vendors to fix and deploy patches, + and the ability of deployers to install those patches. + Automated and secure fix deployment is often not implemented in IoT devices, + although this appears to be changing as the industry matures. + +!!! abstract "Artificial Intelligence and Machine Learning" + + Beyond the changing form factors of computing devices, the increasing use of Artificial Intelligence (AI) + and Machine Learning (ML) in software and systems is also changing the nature of vulnerabilities. + The kinds of problems one might encounter in AI and ML systems include all the traditional problems of + software vulnerabilities, but can extend to issues arising from training algorithms, + training data, models, their distribution and deployment in production systems, and the use of the system. + +!!! abstract "Distributed Ledger and Blockchain" + + Distributed ledger and blockchain technologies also pose challenges to vulnerability coordination. + The kinds of problems one might encounter in distributed ledger and blockchain systems include all the + traditional problems of software vulnerabilities, but can extend to issues arising from the consensus + algorithms, the distributed nature of the system, and the use (and misuse) of the system. + But who do you coordinate with when the system is decentralized and there is no single vendor to fix the problem? + +!!! abstract "Unknown Unknowns" + + We haven't encountered all the coordination problems that will arise in the future. + For example, how might quantum computing change the nature of exploitation or the coordination process? + However, we can be sure that whatever challenges we encounter, some will resemble those we've seen before, + and some will be entirely new. Our plan is to keep learning and adapting this Guide as we go. + +
+ +!!! example "Who Owns an Algorithm?" + + The CERT/CC has already encountered cases where the question of _who owns an algorithm_ + has been a significant factor in the vulnerability coordination process. + + In [VU#425163](https://kb.cert.org/vuls/id/425163) _Machine learning classifiers trained via gradient descent are vulnerable to arbitrary misclassification attack_, + we highlighted the fact that all classifiers trained via gradient descent are vulnerable to adversarial examples. + But with whom should we coordinate to fix this problem? The authors of the paper that defined the gradient descent algorithm? + While those authors might be interested in following up on the problem in a future paper, they are not the ones who have deployed the algorithm in a system, + and publishing a new paper doesn't fix the problem in the deployed systems. + + Well then what about the developers of the software that implements models trained via gradient descent? + Great! Do you happen to know who those developers are? Or even how to tell whether a product or service uses a model trained via gradient descent? + These are not easy questions to answer. + The point is that the traditional model of vulnerability coordination, where the vendor of a product or service is the party best suited to fix the problem, + may not be well-suited to at least some of the problems that arise in AI and ML systems. + +### Increasing Diversity of Approaches to Vulnerability Coordination + +This diversity of requirements forces vendors and researchers alike to reconsider their expectations with respect to the timing and level of +detail provided in vulnerability reports. +Coupled with the proliferation of vendors who are relative novices at internet-enabled devices and are +just becoming exposed to the world of vulnerability research and disclosure, the shift toward IoT has reinvigorated +numerous disclosure debates as the various stakeholders work out their newfound positions. +Similarly, as AI and ML systems become more prevalent, the vulnerability coordination process will need to adapt to the unique challenges +posed by these systems. + +!!! example "The Growing Importance of Vulnerability Response" + + Here's just one example: in 2004, it was considered + [controversial](https://spectrum.ieee.org/unsafe-at-any-broadband-speed) + when the CERT/CC advised users to "use a different browser" in + response to a vulnerability in the most popular browser of the day + ([VU#713878](https://www.kb.cert.org/vuls/id/713878)). + However, consider the implications today if we were + to issue similar advice: "use a different phone," "drive a different + car," or "use a different bank." If those phrases give you pause (as + they do us), you have recognized how the importance of this issue has + grown. + +## Unprepared Vendors + +We often find that vendors of software-centric products are not prepared +to receive and handle vulnerability reports from outside parties, such +as the security research community. Many also lack the ability to +perform their own vulnerability discovery within their development +lifecycles. These difficulties tend to arise from one of two causes: (a) +the vendor is comparatively small or new and has yet to form a product +security incident response capability or (b) the vendor has deep +engineering experience in its traditional product domain but has not +fully incorporated the effect of network enabling its products into its +engineering quality assurance practice. Typically, vendors in the latter +group may have very strong skills in safety engineering or regulatory +compliance, yet their internet security capability is lacking. + +Our experience is that many novice vendors are surprised by the +vulnerability disclosure process. We frequently find ourselves having +conversations that rehash decades of vulnerability coordination and +disclosure conversations with vendors who appear to experience something +similar to the Kübler-Ross stages of grief (denial, anger, bargaining, +depression, and acceptance) during the process. + +## Overly Optimistic Threat Models + +Furthermore, we have observed that overly optimistic threat models are +de rigueur among IoT products. Many IoT products are developed with what +can only be described as naïve threat models that drastically +underestimate the hostility of the environments into which the product +will be deployed. Given what we've seen so far with AI and ML systems, +we anticipate that similarly optimistic threat models will be typical in +these systems as well. + +Over time, exposure to hostile environments will likely lead to a +reassessment of these threat models, but the interim period could be +quite painful for the vendors and deployers of these products who +are caught off guard by the reality of the threat landscape. + +## Composition of Systems + +Even in cases where developers are security-knowledgeable, often they +are composing systems out of components or libraries that may not have +been developed with the same degree of security consideration. This +weakness is especially pernicious in power- or bandwidth-constrained +products and services where the goal of providing lightweight +implementations can supersede the need to provide a minimum level of +security. We believe this is a false economy that only defers a much +larger cost when the product or service has been deployed, +vulnerabilities are discovered, and remediation is difficult. + +## The Future of Vulnerability Coordination + +The future of vulnerability coordination is likely to be even more +complex. While we have seen a number of vendors and researchers +transition to coordinated vulnerability disclosure processes, we have +also encountered even more vendors and researchers who are new to the +disclosure process. + +Recent developments in Artificial Intelligence (AI) and Machine +Learning (ML) have the potential to further complicate the vulnerability +coordination process. As AI and ML are integrated into more products and +services, the potential for vulnerabilities to be discovered and +exploited in these systems will increase. The scope of the problem does +not appear to contract any time soon. + +We already live in a world where mobile devices outnumber traditional +computers, and IoT stands to dwarf mobile computing in terms of the +sheer number of devices soon, if not already. The prevalence of +AI/ML incorporated into new and existing systems seems poised to grow even faster. + +We anticipate that many of the current gaps in +security analysis knowledge and tools surrounding the emergence of IoT +devices will continue to close over the next few years. +And AI and ML might well help to close some of those gaps, even as +they introduce new ones. + +As vulnerability +discovery tools and techniques evolve into these spaces, so must our tools +and processes for coordination and disclosure. Assumptions built into +many vulnerability handling processes about disclosure timing, +coordination channels, development cycles, scanning, patching, and so +forth will need to be reevaluated in the light of hardware-based systems +that are likely to dominate the future internet. diff --git a/mdlint.sh b/mdlint.sh new file mode 100755 index 0000000..321e022 --- /dev/null +++ b/mdlint.sh @@ -0,0 +1,18 @@ +#!/usr/bin/env sh + +# +# Copyright (c) 2023 Carnegie Mellon University and Contributors. +# - see Contributors.md for a full list of Contributors +# - see ContributionInstructions.md for information on how you can Contribute to this project +# Vultron Multiparty Coordinated Vulnerability Disclosure Protocol Prototype is +# licensed under a MIT (SEI)-style license, please see LICENSE.md distributed +# with this Software or contact permission@sei.cmu.edu for full terms. +# Created, in part, with funding and support from the United States Government +# (see Acknowledgments file). This program may include and/or can make use of +# certain third party source code, object code, documentation and other files +# (“Third Party Software”). See LICENSE.md for more details. +# Carnegie Mellon®, CERT® and CERT Coordination Center® are registered in the +# U.S. Patent and Trademark Office by Carnegie Mellon University +# + +markdownlint-cli2 --fix --config .markdownlint-cli2.yaml "**/*.md" "#node_modules/**" diff --git a/mkdocs.yml b/mkdocs.yml new file mode 100644 index 0000000..eb2cbf8 --- /dev/null +++ b/mkdocs.yml @@ -0,0 +1,255 @@ +site_name: CERT® Guide to Coordinated Vulnerability Disclosure +copyright: > + Copyright © 2017-2024 Carnegie Mellon University. +
Change cookie settings +site_url: https://certcc.github.io/CERT-Guide-to-CVD/ +site_description: 'A guide to coordinated vulnerability disclosure (CVD) for security researchers, vendors, and coordinators.' +site_author: 'CERT Coordination Center' +nav: + - Home: 'https://certcc.github.io/' + - CVD Guide: + - 'index.md' + - Why We Wrote This Guide: 'why_this_guide.md' + - About This Guide: 'about.md' + - Learning CVD: + - 'tutorials/index.md' + - This Guide in a Nutshell: 'tutorials/cvd_in_a_nutshell.md' + - CVD Overview: + - 'tutorials/cvd_is_a_process.md' + - CVD Terminology: + - 'tutorials/terminology.md' + - Vulnerability: 'tutorials/terms/vulnerability.md' + - Exploits, Malware, and Incidents: 'tutorials/terms/exp_mw_inc.md' + - Products and Instances: 'tutorials/terms/products_instances.md' + - Vul Response: 'tutorials/terms/vulnerability_response.md' + - Vul Discovery: 'tutorials/terms/vulnerability_discovery.md' + - Vul Scanning: 'tutorials/terms/vulnerability_scanning.md' + - Vul Management: 'tutorials/terms/vulnerability_management.md' + - Coordinated Vulnerability Disclosure: 'tutorials/terms/cvd.md' + - Vulnerability Response Processes: + - Disclosure 101: 'tutorials/response_process/index.md' + - Reporter: 'tutorials/response_process/reporter.md' + - Vendor: 'tutorials/response_process/vendor.md' + - Deployer: 'tutorials/response_process/deployer.md' + - Engaging CERT/CC: + - Coordinating With Us: 'tutorials/coord_certcc/index.md' + - Reporters: 'tutorials/coord_certcc/reporter.md' + - Vendors: 'tutorials/coord_certcc/vendor.md' + - CVD How-To: + - 'howto/index.md' + - Preparation: + - 'howto/preparation/index.md' + - Disclosure Choices: 'howto/preparation/disclosure_choices.md' + - Why Coordinate?: 'howto/preparation/why_coordinate.md' + - Avoid Unnecessary Risk: 'howto/preparation/avoid_risk.md' + - Choosing a Disclosure Policy: 'howto/preparation/choosing_policy.md' + - Communication Topology: 'howto/preparation/topology.md' + - Initiating CVD: + - 'howto/initiation/index.md' + - Providing Useful Reports: 'howto/initiation/useful_reports.md' + - Finding Vendor Contacts: 'howto/initiation/find_vendor_contact.md' + - Unresponsive Vendor: 'howto/initiation/unresponsive_vendor.md' + - Reduce Reporting Friction: 'howto/initiation/reduce_reporting_friction.md' + - Doing CVD: + - 'howto/coordination/index.md' + - Reasons to Engage a Coordinator: 'howto/coordination/coordinator_reasons.md' + - Validation: 'howto/coordination/validation.md' + - Prioritization: 'howto/coordination/prioritization.md' + - Multi-Party CVD: 'howto/coordination/mpcvd.md' + - Response Pacing and Synchronization: 'howto/coordination/response_pacing.md' + - Somebody Stops Responding: 'howto/coordination/somebody_stops_replying.md' + - Embargoes: + - Maintaining Pre-Disclosure Confidentiality: 'howto/coordination/maintaining_secrecy.md' + - Disclosure Timing: 'howto/coordination/disclosure_timing.md' + - Independent Discovery: 'howto/coordination/independent_discovery.md' + - Leaks: 'howto/coordination/leaks.md' + - Active Exploitation: 'howto/coordination/active_exploitation.md' + - Complications: + - Relationships that Go Sideways: 'howto/coordination/relationships_sideways.md' + - Hype, Marketing, and Unwanted Attention: 'howto/coordination/hype.md' + - Troubleshooting CVD: 'howto/coordination/cvd_recipes.md' + - What to Do When Things Go Wrong: 'howto/coordination/general_tips.md' + - Ongoing Operations: + - 'howto/operation/index.md' + - Tooling: + - Secure Communications: 'howto/operation/secure_comms.md' + - Contact Management: 'howto/operation/contact_management.md' + - Case Tracking: 'howto/operation/case_tracking.md' + - Inventory: 'howto/operation/inventory.md' + - Practices: + - Technical Analysis: 'howto/operation/technical_analysis.md' + - Monitoring: 'howto/operation/monitoring.md' + - OpSec: 'howto/operation/opsec.md' + - Staffing: 'howto/operation/staffing.md' + - Understanding CVD: + - 'topics/index.md' + - Principles of CVD: + - 'topics/principles/index.md' + - Reduce Harm: 'topics/principles/reduce_harm.md' + - Presume Benevolence: 'topics/principles/presume_benevolence.md' + - Avoid Surprise: 'topics/principles/avoid_surprise.md' + - Incentivize Desired Behavior: 'topics/principles/incentivize_behavior.md' + - Ethical Considerations: 'topics/principles/ethics.md' + - Process Improvement: 'topics/principles/process_improvement.md' + - CVD is a Wicked Problem: 'topics/principles/wicked_problem.md' + - Roles in CVD: + - 'topics/roles/index.md' + - Finder/Reporter: 'topics/roles/finder.md' + - Vendor: 'topics/roles/vendor.md' + - Deployer: 'topics/roles/deployer.md' + - Coordinator: 'topics/roles/coordinator.md' + - Other Roles: 'topics/roles/other_roles.md' + - Phases of CVD: + - 'topics/phases/index.md' + - Discovery: 'topics/phases/discovery.md' + - Reporting: 'topics/phases/reporting.md' + - Validation: 'topics/phases/validation.md' + - Prioritization: 'topics/phases/prioritization.md' + - Remediation: 'topics/phases/remediation.md' + - Preparing for Public Awareness: 'topics/phases/public_awareness.md' + - Publication: 'topics/phases/publishing.md' + - Deployment: 'topics/phases/deployment.md' + - Special Topics: + - Common Challenges: 'topics/special/challenges.md' + - Finding Vulnerabilities: 'topics/special/discovery.md' + - IoT and CVD: 'topics/special/iot_cvd.md' + - Vulnerability IDs: 'topics/special/vul_ids.md' + - Reference: + - Overview: 'reference/index.md' + - CERT/CC Vulnerability Disclosure Policy: 'reference/certcc_disclosure_policy.md' + - Basic Vul Report Form: 'reference/simple_vrf.md' + - Basic Vul Advisory: 'reference/simple_advisory.md' + - Disclosure Policy Resources: 'reference/disclosure_policy_templates.md' + - Other Resources: 'reference/resources.md' + - About: + - Conclusion: 'about/conclusion.md' + - Community Engagment: 'about/community.md' + - Acknowledgements: 'about/acknowledgements.md' + - Sightings: 'about/sightings.md' + - Other CERT/CC Resources: + - CERT/CC.github.io: 'https://certcc.github.io/' + - SSVC: 'https://certcc.github.io/SSVC/' + - Vultron: 'https://certcc.github.io/Vultron/' + - Legal: + - Contributing to this Guide: 'about/contributing.md' + - Copyright: 'about/copyright.md' +not_in_nav: | + _*.md + _*/**/*.md +theme: + logo: 'assets/cert_seal.svg' + name: 'material' + features: + - content.tabs.link + - content.tooltips + - navigation.footer + - navigation.instant + - navigation.sections + - navigation.tabs + - navigation.tabs.sticky + - navigation.top + - navigation.tracking + - navigation.prune + - navigation.indexes + - search.highlight + - search.suggest + - toc.follow + - toc.integrate + palette: + scheme: 'cmu' + accent: 'red' + icon: + repo: fontawesome/brands/github +plugins: + - include-markdown: + comments: false + - search +# - table-reader: +# data_path: 'data/csvs' +# - bibtex: +# bib_file: 'doc/md_src_files/sources_CERT-Guide-to-CVD.bib' +# - mkdocstrings: +# handlers: +# python: +# paths: [ 'src' ] + - print-site +repo_url: 'https://github.com/CERTCC/CERT-Guide-to-CVD' +repo_name: 'CERTCC/CERT-Guide-to-CVD' +markdown_extensions: + - abbr + - admonition + - attr_list + - def_list + - footnotes + - md_in_html + - pymdownx.arithmatex: + generic: true + - pymdownx.critic + - pymdownx.caret + - pymdownx.details + - pymdownx.emoji: + emoji_index: !!python/name:material.extensions.emoji.twemoji + emoji_generator: !!python/name:material.extensions.emoji.to_svg + - pymdownx.superfences: + custom_fences: + - name: mermaid + class: mermaid + format: !!python/name:pymdownx.superfences.fence_code_format + - pymdownx.keys + - pymdownx.mark + - pymdownx.tabbed: + alternate_style: true + - pymdownx.tasklist: + custom_checkbox: true + - pymdownx.tilde + - pymdownx.snippets: + auto_append: + - docs/_includes/_acronyms.md + - tables +extra: + analytics: + provider: google + property: G-87WECW6HCS + consent: + title: About our use of cookies on this site + description: >- + We use cookies to measure the effectiveness of our documentation and whether users + find what they're searching for. With your consent, you're helping us to + make our documentation better. + See our Privacy Notice for more. + social: + - icon: fontawesome/regular/comments + link: https://github.com/CERTCC/CERT-Guide-to-CVD/discussions + name: CERT-Guide-to-CVD Community Discussions + - icon: material/message-question + link: https://github.com/CERTCC/CERT-Guide-to-CVD/issues/new?template=question.md + name: Ask a Question + - icon: fontawesome/solid/bug + link: https://github.com/CERTCC/CERT-Guide-to-CVD/issues/new?template=bug_report.md + name: Report a Problem + - icon: material/lightbulb-on + link: https://github.com/CERTCC/CERT-Guide-to-CVD/issues/new?template=feature_request.md + name: Request a Feature + - icon: fontawesome/brands/github + link: https://github.com/CERTCC/CERT-Guide-to-CVD + name: CERTCC/CERT-Guide-to-CVD on Github + - icon: fontawesome/regular/envelope + link: mailto:cert@cert.org?subject=CERT-Guide-to-CVD%20Feedback + name: Email CERT/CC + - icon: fontawesome/solid/house + link: https://www.sei.cmu.edu/ + name: Software Engineering Institute +extra_javascript: + # to render math + - javascripts/mathjax.js + - https://polyfill.io/v3/polyfill.min.js?features=es6 + - https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js + # to sort tables + - https://unpkg.com/tablesort@5.3.0/dist/tablesort.min.js + - javascripts/tablesort.js +extra_css: + - stylesheets/extra.css +watch: + - docs +dev_addr: 127.0.0.1:8002 + diff --git a/requirements.txt b/requirements.txt new file mode 100644 index 0000000..f104712 --- /dev/null +++ b/requirements.txt @@ -0,0 +1,9 @@ +mkdocs==1.5.3 +mkdocs-bibtex==2.15.0 +mkdocs-include-markdown-plugin==6.0.5 +mkdocs-table-reader-plugin==2.1.0 +mkdocs-material==9.5.17 +mkdocs-material-extensions==1.3.1 +mkdocstrings==0.24.3 +mkdocstrings-python==1.9.2 +mkdocs-print-site-plugin==2.4.0