diff --git a/docs/_includes/_quick_start.md b/docs/_includes/_quick_start.md index 7a8758f..fcb74a2 100644 --- a/docs/_includes/_quick_start.md +++ b/docs/_includes/_quick_start.md @@ -33,7 +33,7 @@ to achieve. 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) + [Disclosure Policy Resources](../reference/policy_templates/index.md) contains links to a number of disclosure policy examples and templates. @@ -64,7 +64,7 @@ to achieve. [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) + [Disclosure Policy Resources](../reference/policy_templates/index.md) contains links to a number of disclosure policy examples and templates. diff --git a/docs/howto/preparation/choosing_policy.md b/docs/howto/preparation/choosing_policy.md index 53aa72b..5b3c34e 100644 --- a/docs/howto/preparation/choosing_policy.md +++ b/docs/howto/preparation/choosing_policy.md @@ -53,4 +53,4 @@ reporters, vendors, coordinators) can expect in terms of these factors: !!! info "Disclosure Policy Templates" - {% include-markdown "../../reference/disclosure_policy_templates.md" heading-offset=1 start="" end="" %} + {% include-markdown "../../reference/policy_templates/other.md" heading-offset=1 start="" end="" %} diff --git a/docs/reference/index.md b/docs/reference/index.md index 6ad56d2..8c15b73 100644 --- a/docs/reference/index.md +++ b/docs/reference/index.md @@ -8,7 +8,7 @@ These resources include templates, standards, and other materials that can help - :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-clipboard-check-multiple-outline: [Disclosure Policy Resources](policy_templates/index.md) - :material-bookshelf: [CVD Resources and Standards](./resources.md) diff --git a/docs/reference/policy_templates/_consistency_warning.md b/docs/reference/policy_templates/_consistency_warning.md new file mode 100644 index 0000000..108ee26 --- /dev/null +++ b/docs/reference/policy_templates/_consistency_warning.md @@ -0,0 +1,8 @@ +!!! warning "These examples are not internally consistent" + + Because these policy statements are meant to be remixed and adapted for + different organizations and contexts, some of the policy points could + conflict with or mutually exclude others. + It's up to you to edit them into whatever you want your policy to say. + Our hope is that this collection has enough breadth of coverage across issues that the + words address most of what you might want a policy to cover. diff --git a/docs/reference/policy_templates/_policy_tips.md b/docs/reference/policy_templates/_policy_tips.md new file mode 100644 index 0000000..332ccc5 --- /dev/null +++ b/docs/reference/policy_templates/_policy_tips.md @@ -0,0 +1,64 @@ +!!! tip "Policy statements should be clear and simple" + + Each item in a policy should cover a single expectation. + Items should be clear and simple to facilitate interpretation by all participants. + +!!! tip "Use RFC 2119-style language" + + Each item SHOULD use "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", + "MAY", and "OPTIONAL" consistent with their meaning in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). + RFC-style makes clear the distinction between expectations that are recommendations versus those that are requirements. + +!!! tip "Use active voice" + + Write each policy expectation item in the active voice. This means every + statement has a clear actor and an expectation on that actor. `ORGANIZATION` + SHALL..., Reporter MAY..., etc.) Active voice makes it easy to + recognize to whom the expectation applies. + +!!! tip "Use imperative expectations of others and declarative expectations of self" + + In general, expectations of others should use "MAY", "SHOULD", "MUST", "MUST + NOT", "REQUIRED", or "OPTIONAL". + + Expectations that the `ORGANIZATION` sets for itself should prefer "SHALL" + and "SHALL NOT" in place of "MUST" or "MUST NOT". + + Similarly, it seems unlikely that `ORGANIZATION` would use "SHOULD" to refer to + its own behavior, rather preferring to use "SHALL", "SHALL NOT", or "MAY" + formulations. + + Rationale: The policy creator is declaring limits and + expectations on their own behavior, not recommending to others what they + can/should/might do. In other words, use imperatives for others, declaratives + for self. + +!!! tip "Separate expectations by role" + + To the degree possible, separate expectations by role. For example, as we have + done by splitting [reporters](reporters.md) + and [receivers](receivers.md) into separate files. + In a real policy, + these would become different sections of the document. + +!!! tip "Keep it simple / limit complexity" + + Limit the logical complexity of individual expectations. A single conditional + is fine. Consider splitting statements containing multiple conditionals into + separate statements. + +!!! tip "Consider symmetry" + + Consider symmetry in policy expectation items. For example, if you expect + politeness from Reporters, do you also commit to being polite? + +!!! tip "Replace KEYWORDS with specifics" + + In our template statements, we use KEYWORDS to denote specifics that are + stakeholder-specific. + + Replace KEYWORDS with specifics that are relevant to your organization. + + For example, replace `ORGANIZATION` with your organization's name, or + `SLC` with "45 days" if that's your organization's + standard disclosure timeline. diff --git a/docs/reference/policy_templates/_terminology.md b/docs/reference/policy_templates/_terminology.md new file mode 100644 index 0000000..a82be13 --- /dev/null +++ b/docs/reference/policy_templates/_terminology.md @@ -0,0 +1,30 @@ +!!! note "Terminology Notes" + + **Terms from RFC 2119** + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). + + **Terms from ISO, CERT** + The terms *Researcher* or *Reporter* is intended to be consistent with the terms *Finder* and/or *Reporter* as used in ISO/IEC 29147:2014(E) and the [CERT® Guide to Coordinated Vulnerability Disclosure](../../topics/roles/finder.md). + + **Other Terms** + + `ORGANIZATION` + : the name of an organization or entity, specifically the one creating this policy. + + `SYSTEM SCOPE` + : A defined set of systems covered by this policy. E.g., "`ORGANIZATION`'s information systems", "`ORGANIZATION`'s public web sites", "`PRODUCT` versions X through Y", "Critical infrastructure information systems", or any other similar scope. + + `JURISDICTION` + : the territorial, political, or governmental scope of a regulatory authority + + `SLC` + : Service Level Commitment, typically expressed in terms of the minimum or maximum time until some event trigger. For example: at least 45 days, not more than 90 days, within 2 business days, etc. + + `PUBLICATION CHANNEL` + : A specific medium through which information is conveyed, e.g., a web site, mailing list, Twitter, RSS or Atom Feed, or database. + + `BUG BOUNTY` + : A type of Vulnerability Disclosure Program in which the `ORGANIZATION` compensates reporters for reports meeting specific criteria. + + `REPORTING CHANNEL` + : A specific medium through which vulnerability reports are communicated from a Reporter to the `ORGANIZATION`. Examples include: an email address, a web form, or a bug tracking platform. diff --git a/docs/reference/policy_templates/_usage.md b/docs/reference/policy_templates/_usage.md new file mode 100644 index 0000000..730d59d --- /dev/null +++ b/docs/reference/policy_templates/_usage.md @@ -0,0 +1,37 @@ +!!! tip "How To Use These Templates" + + Organizations will likely find that some expectations do not apply to their + situation based on the kind of stakeholder they are. In particular we anticipate + that + [product vendors](../../topics/roles/vendor.md), + [service providers](../../topics/roles/deployer.md), + and + [coordinators](../../topics/roles/coordinator.md) will have related but + distinct needs. Inclusion or exclusion of items from these templates into your + organization's policy should be based on which combination of stakeholder roles + you expect to play. + + Here's a checklist of tasks you should complete in order to make use of these + templates. + + - [x] Review the content of the [Disclosure Policy Style Guide](./style_guide.md). + - [x] Review the content of the [Reporters](./reporters.md) and [Receivers](./receivers.md) files. + - [x] Select the policy expectation items you want to use. + - [x] Adjust the recommendation strength (e.g., change some of the SHOULDs to MUSTs or MAYs to SHOULD NOTs etc.). + - [x] Adjust the wording of the items to fit your organization's style or needs. + - [x] Replace any KEYWORDS with an appropriate substitution (e.g., "45 days" + instead of `SLC`"). + - [x] Construct a single policy document from the collected items. + - [x] Add any needed introduction, boilerplate, or legal info to the document. + - [x] Review the entire document for internal consistency and fix any + contradictions. + - [x] Review the document for external consistency with other organization policies, + applicable laws, regulations, etc. + - [x] Get approval for the policy and to publish the document from necessary decision makers + - [x] Establish sufficient operational capability in order to provide the service(s) the policy commits you to offer. + - [x] Publish the policy + + !!! note "Disclaimer" + + We are not lawyers, and this is not legal advice. + You are encouraged to consult your own legal counsel in the process of creating your disclosure policy. diff --git a/docs/reference/policy_templates/index.md b/docs/reference/policy_templates/index.md new file mode 100644 index 0000000..84ae737 --- /dev/null +++ b/docs/reference/policy_templates/index.md @@ -0,0 +1,41 @@ +# Vulnerability Disclosure Policy Templates + +In recent years the CERT/CC has advised a number of organizations on their +vulnerability disclosure policies. +This section contains a collection of resources intended for use in +constructing a vulnerability disclosure policy. +Here we are attempting to capture common +verbiage in order to help others develop or improve their own policies. We've +taken these items from a variety of vulnerability disclosure policies including +[our own](../certcc_disclosure_policy.md), generalized them, organized them by topic, and assembled them into this +collection. + +This collection is a general set of templates from which you can derive and +spawn a disclosure policy for an organization. + +
+ +!!! tip "How to Use This Collection" + + This collection of example policy statements is meant to be remixed and adapted for different + organizations and contexts. It is unlikely that any single organization would + choose to adopt all of these items wholesale without some modification. + +- :material-feather: [Style Guide](./style_guide.md) + + --- + {%include-markdown "./style_guide.md" start="" end="" %} + +- :material-set-left-center: [Setting Expectations for Reporters](./reporters.md) + + --- + {%include-markdown "./reporters.md" start="" end="" %} + +- :material-set-center-right: [Setting Expectations for Receivers](./receivers.md) + + --- + {%include-markdown "./receivers.md" start="" end="" %} + +
+ +{% include-markdown "./_usage.md" %} diff --git a/docs/reference/disclosure_policy_templates.md b/docs/reference/policy_templates/other.md similarity index 86% rename from docs/reference/disclosure_policy_templates.md rename to docs/reference/policy_templates/other.md index 406327d..8eaff97 100644 --- a/docs/reference/disclosure_policy_templates.md +++ b/docs/reference/policy_templates/other.md @@ -2,7 +2,9 @@ -Following are some resources that can help you create a disclosure policy: +In addition to the [Disclosure Policy Templates](./index.md) we provide as part of this guide, +there are many other resources available to help you create a vulnerability disclosure policy. +Here are a few examples: - CISA provides a [Vulnerability Disclosure Policy Template](https://www.cisa.gov/vulnerability-disclosure-policy-template){:target="_blank"} for U.S. Federal Agencies. This template is also useful as a starting point for other organizations @@ -13,9 +15,6 @@ Following are some resources that can help you create a disclosure policy: - The [disclose.io](https://disclose.io/){:target="_blank"} [Policymaker](https://policymaker.disclose.io/policymaker/introduction){:target="_blank"} 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){:target="_blank"} - 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){:target="_blank"} 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){:target="_blank"} provides guidelines for vulnerability disclosure, including a section on required, recommended, and optional policy elements. diff --git a/docs/reference/policy_templates/receivers.md b/docs/reference/policy_templates/receivers.md new file mode 100644 index 0000000..9c7e784 --- /dev/null +++ b/docs/reference/policy_templates/receivers.md @@ -0,0 +1,107 @@ +# Vulnerability Disclosure Policy Templates for Receivers + +This collection of policy statement templates describe expectations for organizations +receiving vulnerability reports. +Report Receivers might include +[Vendors](../../topics/roles/vendor.md), +[Coordinators](../../topics/roles/coordinator.md), +[Deployers](../../topics/roles/deployer.md), +or other organizations that receive vulnerability reports. + +## Tips and Usage Notes + +{% include-markdown "./_usage.md" %} +{% include-markdown "./_terminology.md" %} +{% include-markdown "./_consistency_warning.md" %} + +## Template Policy Statements + +`ORGANIZATION` SHALL deal in good faith with Reporters who discover, test, and report vulnerabilities or indicators of vulnerabilities in accordance with these guidelines. + +## General + +* `ORGANIZATION` MAY modify the terms of this policy or terminate the policy at any time. + +* `ORGANIZATION` SHALL use information reported to this program for defensive purposes only; to mitigate or remediate vulnerabilities in our networks or applications, or the applications of our vendors. + +## Case handling + +* `ORGANIZATION` 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. + +* In the event that `ORGANIZATION` declines to coordinate a vulnerability report, the Reporter SHOULD proceed to coordinate with any other affected vendor(s). Additionally, the Reporter MAY proceed with public disclosure at their discretion. + +* `ORGANIZATION` SHALL investigate every reported vulnerability and strive to ensure that appropriate steps are taken to mitigate risk and remediate reported vulnerabilities. + +* `ORGANIZATION` SHALL, to the best of our ability, validate the existence of the vulnerability + +* `ORGANIZATION` SHALL determine an appropriate timeframe for mitigation development and deployment for vulnerabilities reported in systems it controls. + +## Coordination with reporters + +* `ORGANIZATION` SHALL acknowledge receipt of vulnerability reports via email within `SLC`. + +* `ORGANIZATION` MAY contact the Reporter for further information. + +* `ORGANIZATION` SHALL inform the Reporter of the results of our validation, as appropriate, and accordingly provide status updates as remediation of the vulnerability is underway. + +* `ORGANIZATION` SHALL include credit to the reporter in any published vulnerability report unless otherwise requested by the reporter. + +* In the event that `ORGANIZATION` chooses to publicly disclose the reported vulnerability, `ORGANIZATION` SHALL recognize your contribution to improving our security if you are the first to report a unique vulnerability, and your report triggers a code or configuration change. + +* `ORGANIZATION` MAY forward the name and contact information of the Reporter to any affected vendors unless otherwise requested by the reporter. + +* `ORGANIZATION` SHALL forward the name and contact information of the reporter to the affected vendors unless otherwise requested by the reporter. + +* `ORGANIZATION` SHALL 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. + +* `ORGANIZATION` MAY adjust its publication timeframe to accommodate reporter constraints if that timing is otherwise compatible with this policy. In most cases such an adjustment would be expected to represent a delay rather than an acceleration of the publication schedule. Examples include delaying publication to coincide with conference presentations. + +* `ORGANIZATION` SHALL NOT require Reporters to enter into a customer relationship, non-disclosure agreement (NDA) or any other contractual or financial obligation as a condition of receiving or coordinating vulnerability reports. + +## Coordination with vendors + +* In the event that `ORGANIZATION` determines the reported vulnerability is consequent to a vulnerability in a generally available product or service, `ORGANIZATION` MAY report the vulnerability to the affected vendor(s), service provider(s), or third party vulnerability coordination service(s) in order to enable the product or service to be fixed. + +* `ORGANIZATION` SHALL make a good faith effort to inform vendors of reported vulnerabilities prior to public disclosure. + +* `ORGANIZATION` SHALL forward vulnerability reports to the affected vendor(s) as soon as practical after we receive the report. + +* `ORGANIZATION` SHALL apprise any affected vendors of our publication plans and negotiate alternate publication schedules with the affected vendors when required. + +* `ORGANIZATION` SHALL provide the vendor the opportunity to include a vendor statement within our public disclosure document. + +* `ORGANIZATION` SHALL NOT withhold vendor-supplied information simply because it disagrees with our assessment of the problem. + +* `ORGANIZATION` SHALL notify affected vendors of any public disclosure plans. + +* `ORGANIZATION` SHALL NOT reveal information provided in confidence by any vendor. + +* `ORGANIZATION` SHALL act in accordance with the expectations of Reporters set forth in this policy when acting as a Reporter to other organizations (vendors, coordinators, etc.). + +## Coordination with others + +* `ORGANIZATION` MAY engage the services of a third party coordination service (e.g., CERT/CC, DHS CISA) to assist in resolving any conflicts that cannot be resolved between the Reporter and `ORGANIZATION`. + +* `ORGANIZATION` MAY, at our discretion, provide reported vulnerability 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), service providers, community experts, sponsors, and sites that are part of a national critical infrastructure, if we believe those sites to be at risk. + +## Public disclosure + +* `ORGANIZATION` SHALL determine the type and schedule of our public disclosure of the vulnerability. + +* `ORGANIZATION` MAY disclose reported vulnerabilities reported to the public N days after the initial report, regardless of the existence or availability of patches or workarounds from affected vendors. + +* `ORGANIZATION` MAY disclose vulnerabilities to the public earlier or later than N days due to extenuating circumstances, including but not limited to active exploitation, threats of an especially serious (or trivial) nature, or situations that require changes to an established standard. + +* `ORGANIZATION` MAY consult with the Reporter and any affected vendor(s) to determine the appropriate public disclosure timing and details. + +* `ORGANIZATION` SHALL balance the need of the public to be informed of security vulnerabilities with vendors' need for time to respond effectively. + +* `ORGANIZATION`'s final determination of a publication schedule SHALL be based on the best interests of the community overall. + +* `ORGANIZATION` SHALL publish public disclosures via `PUBLICATION CHANNEL`. + +* `ORGANIZATION` MAY disclose to the public the prior existence of vulnerabilities already fixed by `ORGANIZATION`, including potentially details of the vulnerability, indicators of vulnerability, or the nature (but not content) of information rendered available by the vulnerability. + +* `ORGANIZATION` SHALL make our disclosure determinations based on relevant factors such as but not limited to: whether the vulnerability has already been publicly disclosed, the severity of the vulnerability, potential impact to critical infrastructure, possible threat to public health and safety, immediate mitigations available, vendor responsiveness and feasibility for creating an upgrade or patch, and vendor estimate of time required for customers to obtain, test, and apply the patch. Active exploitation, threats of an especially serious nature, or situations that require changes to an established standard may result in earlier or later disclosure. + +* `ORGANIZATION` MAY disclose product vulnerabilities `SLC` after the initial contact is made, regardless of the existence or availability of patches or workarounds from affected vendors in cases where a product is affected and the vendor is unresponsive, or fails to establish a reasonable timeframe for remediation. diff --git a/docs/reference/policy_templates/reporters.md b/docs/reference/policy_templates/reporters.md new file mode 100644 index 0000000..d0bb14f --- /dev/null +++ b/docs/reference/policy_templates/reporters.md @@ -0,0 +1,104 @@ +# Vulnerability Disclosure Policy Templates for Reporters + +This collection of policy statement templates describe expectations for reporters participating in a +vulnerability disclosure program. + +## Tips and Usage Notes + +{% include-markdown "./_usage.md" %} +{% include-markdown "./_terminology.md" %} +{% include-markdown "./_consistency_warning.md" %} + +## Template Policy Statements + +Reporters MUST adhere to the following guidelines. + +## General + +* Reporters MUST comply with all applicable `JURISDICTION` laws in connection with security research activities or other participation in this vulnerability disclosure program. + +* Reporters SHOULD make a good faith effort to notify and work directly with the affected vendor(s) or service providers prior to publicly disclosing vulnerability reports. + +## Scope of Authorized Testing + +* Reporters MAY test `SYSTEM SCOPE` to detect a vulnerability for the sole purpose of providing `ORGANIZATION` information about that vulnerability. + +* Reporters SHOULD only test against test accounts owned by the Reporter or with explicit permission from the account holder. + +* Reporters MUST avoid harm to `ORGANIZATION`'s information systems and operations. + +* Reporters MUST make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction or manipulation of data. + +* Reporters MUST stop testing once that testing has established that a vulnerability exists, or sensitive data has been encountered. Sensitive data includes personally identifiable information, financial information (e.g., account numbers), proprietary information or trade secrets. + +* Reporters MUST NOT test any services not expressly listed in `SYSTEM SCOPE`, including any connected services + +* Reporters MUST NOT exploit any vulnerability beyond the minimal amount of testing required to prove that the vulnerability exists or to identify an indicator related to that vulnerability. + +* Reporters MUST NOT intentionally access the content of any communications, data, or information transiting or stored on `ORGANIZATION`'s information system(s) – except to the extent that the information is directly related to a vulnerability and the access is necessary to prove that the vulnerability exists. + +* Reporters MUST NOT exfiltrate any data under any circumstances. + +* Reporters MUST NOT intentionally compromise the privacy or safety of `ORGANIZATION`'s personnel, customers, the general public, or any legitimate third parties. + +* Reporters MUST NOT use any exploit to compromise, alter, or exfiltrate data + +* Reporters SHOULD NOT establish command line access and/or persistence + +* Reporters MUST NOT exploit any vulnerabilities found to pivot to other systems. + +* Reporters MUST NOT intentionally compromise the intellectual property or other commercial or financial interests of any `ORGANIZATION`'s personnel or entities, customers, or any legitimate third parties. + +* Reporters MUST NOT cause a denial of any legitimate services in the course of their testing. + +* Reporters MUST NOT perform physical access testing (e.g. office access, open doors, tailgating, or other trespass). + +* Reporters MUST NOT conduct social engineering in any form of `ORGANIZATION` personnel or contractors. + +* Reporters SHOULD contact `ORGANIZATION` at POINT OF CONTACT if at any point you are uncertain of whether to proceed with testing. + +## Coordination with `ORGANIZATION` + +* Reporters SHOULD submit vulnerability reports to `ORGANIZATION` via `REPORTING CHANNEL`. + +* Reporters MAY be eligible for one or more bug bounties. See `BUG BOUNTY` for details where applicable. + +* Reporters SHOULD submit high quality reports. + +* Reporters SHOULD include sufficient descriptive details to permit `ORGANIZATION` and/or the affected vendor(s) to accurately reproduce the vulnerable behavior. + +* Reporters SHOULD NOT report unanalyzed crash dumps or fuzzer output unless accompanied by a sufficiently detailed explanation of how they represent a security vulnerability. + +* Reporters SHOULD report other vulnerabilities found incidental to their in-scope testing even if those vulnerabilities would be otherwise considered out-of-scope. For example, while testing an in-scope system the reporter finds it to be exposing data from out-of-scope system. These are still reportable vulnerabilities. + +* Reporters MUST keep confidential any information about vulnerabilities discovered for `SLC` after you have notified `ORGANIZATION`. Notwithstanding, this expectation does not preclude Reporters from simultaneously coordinating the vulnerability report with other affected parties (vendors, service providers, coordinators, etc.) + +* Reporters MAY include a proof-of-concept exploit if available. + +* Reporters MAY request that their contact information be withheld from all affected vendor(s). + +* Reporters MAY request not to be named in the acknowledgements of `ORGANIZATION`'s public disclosures. + +* Reporters MUST NOT submit a high-volume of low-quality reports. + +* Reporters MUST NOT require `ORGANIZATION` to enter into a customer relationship, non-disclosure agreement (NDA) or any other contractual or financial obligation as a condition of receiving or coordinating vulnerability reports. + +* Reporters MUST NOT demand compensation in return for reporting vulnerability information reported outside of an explicit bug bounty program. + +## Coordination with vendors + +* In the event that the Reporter finds a vulnerability in a `ORGANIZATION``SYSTEM SCOPE` consequent to a vulnerability in a generally available product or service, the Reporter MAY report the vulnerability to the affected vendor(s), service provider(s), or third party vulnerability coordination service(s) in order to enable the product or service to be fixed. + +## Coordination with others + +* Reporters MAY engage the services of a third party coordination service (e.g., CERT/CC, DHS CISA) to assist in resolving any conflicts that cannot be resolved between the Reporter and `ORGANIZATION`. + +* Reporters SHOULD NOT disclose any details of any extant `ORGANIZATION``SYSTEM SCOPE` vulnerability, or any indicators of vulnerability to any party not already aware at the time the report is submitted to `ORGANIZATION`. + +## Public disclosure + +* Reporters MAY disclose to the public the prior existence of vulnerabilities already fixed by `ORGANIZATION`, including potentially details of the vulnerability, indicators of vulnerability, or the nature (but not content) of information rendered available by the vulnerability. + +* Reporters choosing to disclose to the public SHOULD do so in consultation with `ORGANIZATION`. + +* Reporters MUST NOT disclose any incidental proprietary data revealed during testing or the content of information rendered available by the vulnerability to any party not already aware at the time the report is submitted to `ORGANIZATION`. diff --git a/docs/reference/policy_templates/style_guide.md b/docs/reference/policy_templates/style_guide.md new file mode 100644 index 0000000..50b805d --- /dev/null +++ b/docs/reference/policy_templates/style_guide.md @@ -0,0 +1,13 @@ +# Disclosure Policy Style Guide + + +We have compiled this style guide to ensure our template statements +can be used to create a policy that is clear, consistent, and easy to read. +We also think it's likely to be useful when constructing your policy too. + + +
+ +{% include-markdown "./_policy_tips.md" %} + +
diff --git a/mkdocs.yml b/mkdocs.yml index 9b3c6f0..ec5777c 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -119,8 +119,13 @@ nav: - 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' + - Disclosure Policy Templates: + - 'reference/policy_templates/index.md' + - Style Guide: 'reference/policy_templates/style_guide.md' + - Reporters: 'reference/policy_templates/reporters.md' + - Receivers: 'reference/policy_templates/receivers.md' + - More Policy Resources: 'reference/policy_templates/other.md' + - Other CVD Resources: 'reference/resources.md' - About: - Conclusion: 'about/conclusion.md' - Community Engagement: 'about/community.md'