Vulnerability Disclosure Guidelines
of the
Common Computing Security Standards Forum

1. Introduction. This document is the Common Computing Security Standards guidelines on vulnerability disclosure and is intended to be a minimum framework that each participating security vendor will adopt and follow with respect to vulnerability disclosure. These guidelines originate primarily from the Vulnerability Disclosure Framework published on January 13, 2004 by the National Infrastructure Advisory Council.

2. Applicability. These guidelines apply to security vendors that are members of CCSS while interacting with discovers, coordinators, and end users with respect to vulnerability disclosures.

3. Definitions.

3.1 "Coordinator" means an entity responsible for managing and coordinating responses to vulnerabilities. Coordinators also serve as unbiased, independent evaluators of severity and may act as a medium for communicating with the public.

3.2 "Discoverers" means any individuals or organizations that find vulnerabilities.

3.3 "End User" means anyone using a Vendor's product that could be affected by a disclosed vulnerability.

3.4 "Vendors" means any member of the CCSS forum that develops and distributes security software.

3.5 "Vulnerability" means a set of conditions that could lead to a failure of the confidentiality, integrity, or availability of an information system. Examples may include executing commands as another user, accessing data in excess of specified or expected permission, posing as another user or service within a system, causing an abnormal denial of service, inadvertently or intentionally destroying data without permission, and exploiting an encryption implementation weakness that significantly reduces the time or computation required to recover the plaintext from an encrypted message.

3.6 The words "should", "must", "might", "can", "may", and other key words have the meaning assigned in RFC 2119.

4. Discovery. These vulnerability disclosure guidelines apply to Vendors only if:

4.1 Analysis. The Discoverer has well-defined root-cause analysis processes with clearly assigned responsibilities for performing an analysis for every attack.

4.2 Testing. Discover uses methodical and repeatable testing methods. Testing should be on full, current versions of the software and utilize methods and tools available in existing and relevant environments.

5. Reporting.

5.1 Communication.

  1. Discoverers should communicate directly with Vendors or may communicate through a Coordinator.
  2. If the vulnerability affects a single Vendor, the Discovered should first contact that Vendor directly. If a large number of Vendors are affected, the Discoverer should use a Coordinator to ensure that each Vendor is contacted.
  3. If a Discoverer cannot identify the correct channel for communicating security issues, the Discoverer should contact a Coordinator for assistance.
  4. Discoverers should never send full technical details unless 1) Discoverer is sure who will be handling the vulnerability within a vendor's organization or 2) Discoverer has received an initial response from Vendor.

5.2 Mechanisms.

  1. Vendors must adopt a common process for receiving and handling vulnerability reports. This process should be made publically available through the vendor's website.
  2. A common reporting process can be an email address such as:
    security-alert@example.com
    security@example.com
    secure@example.com
    support@example.com
    info@example.com
  3. Vendor websites should have a section that is easily accessible off of the Vendor's main page that is devoted to security such as www.example.com/security. Information on the vulnerability site can include contact information, information about the security teams working on vulnerabilities, copyright and spam abuse contacts, etc., and a vulnerability management section that explains how to report and information on advisories.
  4. Vendors should make weekend and holiday schedules information available so that a Discoverer may determine accurately on which day the initial contact period in section 5.3 expires and a response should have been received.

5.3 Response Times.

  1. Vendors should acknowledge receipt of Discoverer's report in a timely manner, typically within seven business days of the initial contact. The seven-day timeline is established by the Vendor, not the Discoverer as work schedules that may not be obvious to Discoverers.
  2. The acknowledgement should be a personal response that includes an initial status report instead of an automated message.
  3. The seven-day response guideline can be accelerated by Discoverer if a vulnerability exposes actual attacks as opposed to theoretical vulnerabilities.
  4. If a Vendor fails to send a satisfactory acknowledgement, the Discoverer should escalate the issue with the Vendor.
  5. If the Discoverer is still unsuccessful, the Discoverer should use a Coordinator meeting the requirements in section 11 to contact the Vendor.
  6. If the Coordinator is unable to contact the Vendor, the Discovered should use its best judgment in proceeding.
  7. Per section 5.1(iv), the Discoverer should not provide complete details about any vulnerability prior to receiving a response from the Vendor.

5.4 Details.

  1. After receiving a response from the Vendor, Discoverers must provide the Vendor with all technical information and related materials the vendor would need to reproduce the vulnerability. The Discoverer should also provide complete revision information, including his or her implementation's current patch level, and a description of the technology's environment (e.g. hardware, configuration, other applications installed, relevant details about the network topology, firewall rules, and anything else that may be of use).
  2. Vulnerability Information should only be sent via encrypted communication.
  3. If the Discoverer shares exploit code, the Discoverer, Vendor, and any involved Coordinator should use extreme care to ensure that it is properly labeled and protected.
  4. The Discoverer should immediately notify the Vendor or Coordinator of any new information or errors in the original report.

6. Protection

6.1 Method of Protection.

  1. Vendors must use contracts and security controls to protect vulnerability information.
  2. Contract provisions should include provisions for confidentiality, scope of disclosure, terms regarding how and when the information may be disclosed to others and liability for breach.

6.2 Email Protection

  1. E-mails related to managing vulnerabilities should be both encrypted and electronically signed by all participating parties, whenever possible.
  2. Emails should be signed to ensure authentication and non-repudiation of all participants and preserve the integrity and confidentiality of message contents.

6.3 Before Publication.

  1. Discovers and Vendors must protect vulnerability information from leaking to external parties between the time of reporting and the final public release.
  2. Reasonable protection measures include isolating the computer systems involved, preventing access to potentially sensitive information related to the vulnerability, and encrypting any materials that are at risk of leaking.
  3. Vendors should have a digital certificate to protect information while in transit from a Discoverer or Coordinator.

6.4 Policies.

  1. Vendors must develop protection policies and practices, including both physical and information system elements, to isolate vulnerability information, exploit code, and related analysis.
  2. At least until the phase when the public notification process begins, vulnerability information should be kept confidential and distributed on a limited basis to Vendor personnel who are tasked to work on solutions and/or develop the public advisories
  3. Vendors should also provide for a secure environment for validating and testing vulnerabilities and developing appropriate solutions.

7. Evaluation

7.1 Vulnerability Processes.

  1. Vendors must adopt internal policies that have a well-defined root-cause analysis process and clearly assigned responsibilities for performing this analysis processes.
  2. Vendors must establish an augmentation capability, resourced with appropriate skill sets and training, to help existing response teams scale to multiple-vulnerability incidents.

7.2 Evaluation

  1. After a vulnerability is reported, the Vendor must evaluate and work with the Discoverer to repeat the conditions under which the vulnerability was discovered and verify that the exploit reveals a genuine, previously unknown and unpatched vulnerability.
  2. Vendor should keep the Discoverer informed regarding progress, enlisting the Discoverer's help as appropriate to recreate the situation demonstrating the security issue.
  3. Vendor and Discoverer should discuss patch timelines and disclosure plans together.

7.3 Threat Rating.

  1. Vendors should score each received vulnerability to determine the severity of the vulnerability and the importance of remediation efforts.
  2. Scores assigned to a specific vulnerability may be altered during the course of investigation to reflect the results of investigation or additional developments. For example, confirmed reports indicating the vulnerability has been exploited by malicious actors will result in a significant change in the score. Similarly, if the existence of a vulnerability is contradicted by research or if its impact on computer systems is demonstrated to be less significant than reported, a vulnerability score will be lowered.
  3. If the Discoverer and Vendor disagree about the seriousness of a threat, a Coordinator should be used to assess the risk posed by the vulnerability.

7.4 Reproduce.

  1. If the Vendor cannot verify the discoverer's claims, the Vendor should contact the Discoverer for more information.
  2. Discoverer should provide this information (e.g., screenshots, stack dumps, debugger output, exploit code, their own affected binary).
  3. If Vendor still cannot replicate the vulnerability, the Discoverer should corroborate the vulnerability with a Coordinator.

7.5 Other Vendors.

  1. A Vendor's response team should proactively warn other Vendors of possible hazards to their products discovered when evaluating Vulnerabilities.
  2. If the vulnerability affects the products of many Vendors, a Coordinator should be used.

7.6 Patching

  1. Vendors should develop fixes for vulnerabilities according to the time line established with the Discoverer.
  2. Vendors should test the fix to validate that the fix does not expose any undesired effects.
  3. The vendor should test the patch in multiple environments that imitate End User implementation of the product.

8. Notification and Closure

8.1 Notification.

  1. After the Vendor is satisfied that a fix is effective and not harmful to most customer software environments, the Vendor notifies End Users and the general public.
  2. Vendors should notify all End Users that could be affected by a significant security issues at the same time.
  3. Vendors should provide an avenue for End Users to proactively (opt-in) sign up to receive security advisory information from the Vendor.
  4. Vendors should provide additional or alternate steps to remedying a vulnerability if Vendor believes a remedy could be a threat to a critical infrastructure. The steps can be wholly dependent on the critical infrastructure at risk and the nature of the threat.

8.2 Monitoring for Active Exploitation.

  1. Vendors must have a contingency plan for urgently disclosing vulnerabilities to End Users.
  2. Vendors should have someone with a designated responsibility of monitoring for malicious exploitation.

8.3 New Discoveries.

  1. Any new collateral effects, modifications of the malicious exploit, or new discoveries of the vulnerability or patch's effects on installations should be fed back to the Vendor that issued the patch.
  2. Vendor must update advisories as appropriate, generally until further updates are no longer relevant.
  3. Vendor may consider the matter closed if Vendor has confirmed with a high percentage of customers that the affected software is patched; the affected software is obsolete; or the vulnerability and its solution are known for a long time.

8.4 Deprecated or Obsolete Software and Hardware.

  1. Vendor is not required to fix vulnerabilities on any deprecated software or hardware.
  2. Vendor's notification for end of life should give End Users clear notification about when the product will reach its end-of-life status and will not be further supported.
  3. Vendor should provide enough advanced notice to allow End Users to replace deprecated products.
  4. Vendor should support deprecated products from the date of the notice until the actual effective date of the deprecation.
  5. After the deprecation is effective, Vendors should still send out notices to End Users about detected vulnerabilities along with a recommendation that they upgrade their product.
  6. Discoverers should report vulnerabilities about recently superseded software to Vendors to help promote secure upgrades by End Users.
  7. Discovers and Vendors should work together to publish vulnerabilities about deprecated software that has a large installation base as an encouragement for End Users to install secure upgrades of vulnerable versions.

9. Publication

9.1 Timeline.

  1. The Discoverer and the Vendor must negotiate a timeline for the release of information and patches.
  2. The Discoverer and the Vendor may use a coordinator to assist with this process.
  3. When developing the timeline, Discoverers should consider the vendor's patch development and testing time, and Vendors should consider the risks of inadvertent disclosure and independent discovery by others.
  4. Discovers should recognize that Vendors sometimes take months to correct security vulnerabilities or that the flaw could be a severe design error that requires significant effort to fix.
  5. If all attempts to work with a Vendor directly and through a Coordinator fail, the Discoverer may publish information on a vulnerability for which no fix or workaround exists.

9.2 Details

  1. Discoverer should determine the appropriate amount of technical detail to include in disclosures.
  2. The amount of information disclosed should provide sufficient detail without unnecessarily jeopardizing users.
  3. Vendors should publicly acknowledge discoverers in all advisories related to the vulnerability if the discoverer agrees to be recognized. An acknowledgement could be as simple as, "The issue was reported to [vendor] by [discoverer]."9
  4. Discoverers should not release any exploit code or detailed guide to exploiting the vulnerability when publishing advisories.

9.3 Leaks. If reported vulnerability information about the vulnerability is leaked during the discovery process, the Discoverer should coordinate with the affected Vendor(s) or a Coordinator to assist in the release of a vendor advisory basing the amount of detail that has been exposed.

9.4 No Publication Required.

  1. Vendors may fix vulnerabilities without issuing an advisory or notifying End Users.
  2. Discoverers finding an already corrected vulnerability may publish an advisory on the vulnerability after contacting the Vendor and requesting that the Vendor issue an advisory.
  3. Discoverer should tell the Vendor that it intends to publish the advisory before doing so.

10. End Users

10.1 Dependencies.

  1. End Users should understand the assets on which they depend.
  2. End Users should assess their critical systems to understand which products, protocols, and technologies they have deployed.
  3. End Users should understand that no external entity can perfectly assess vulnerabilities for them and they are responsible for reacting promptly and appropriately when vulnerability information is brought to them.

10.2 Support-Level Agreements.

  1. End Users should determine the appropriate internal response that will be available if a vulnerability is detected
  2. End Users should designate a point of contact that can assist Vendor in carrying out a deployment plan that addresses vulnerabilities for affected internal entities.

10.3 Deployment Plan and Process. End Users should have a plan for deploying fixes to discovered vulnerabilities. This plan should include an assessment that verifies the existence of the vulnerability, an assessment that determines the impact of exploitation, a process of obtaining fixes from Vendors, and a plan to evaluate the impact of a fix on the End User's systems.

10.4 Assignment of Tasks.

  1. Once notified of a vulnerability and the corresponding fix, End Users should assign resources to carry out the deployment and mitigation plan.
  2. End Users failing to take appropriate action after receiving notice by the Vendor should bear the consequences.

10.5 Protection of Information.

  1. End Users should protect sensitive information regarding vulnerabilities and exploits.
  2. End Users should protect all information regarding the vulnerability until after Vendor or Discover has made the information publically available and until after testing proves that a fix has not created an unacceptable risk in the End User's network.

10.6 Disclosure to Public. End Users determine if and when informing their customers about a vulnerability is necessary. End Users should consider applicable law and the party's contracts in making this decision.

10.7 Republishing Advisories. End Users who maintain lists or republish advisories should check with vendors frequently to maintain up-to-date information.

11. Coordinators

11.1 Characteristics.

  1. Coordinators selected by Vendors should have a constituency and be recognized and trusted by Vendors, Discovers, and End Users.
  2. Coordinators should be a well-known public interface with international reach that can quickly contact all affected parties.

11.2 Protection of Information.

  1. Coordinators should take great care in safeguarding information.
  2. Coordinators should use secure communication with parties, including using secure electronic mail, procedures to guard against information leakage, and procedures and tools to compartmentalize information,

11.3 Multiple Vulnerabilities

  1. Coordinators may work on multiple vulnerabilities simultaneously. However, Coordinators must take care to ensure that multiple streams of work are prioritized correctly according to 1) the goals of the coordinating body, 2) the needs of the parties, and 3) available resources.
  2. Each coordinator should evaluate vulnerabilities independently in order to develop a locally correct remediation plan.

11.4 Reporting.

  1. Coordinators should establish a well-known reporting mechanism.
  2. Upon receipt of a vulnerability report, the coordinator should establish communication with an individual in the Vendor's organization that has the authority and capacity to make statements regarding the disposition of a Vendor's product with respect to the reported vulnerability.
  3. This communication should be through mutually acceptable communication channels. This should usually not be ordinary support channels.

11.5 Handling Dependencies. Coordinators should utilize experts and decisions with a willingness to conduct significant research into software, hardware, and firmware dependencies in order to provide complete and correct advice.

11.6 Release Schedules. Coordinators should assist in negotiating a release schedule among the Vendors and Discoverers.

11.7 Advisories. Coordinators should:

  1. Validate the authenticity of any alerts considered for rebroadcasting,
  2. Always refer to source material and provide appropriate citations and credit,
  3. Always provide a pointer to vendor-supplied alerts when available,
  4. Recognize their limitations (a coordinator may indeed be a security expert, but no individual or organization can be product experts for all products), and
  5. Pay careful attention to quantifiers and modifiers like "may," "should," "some," "any," or "every."