SPI Labs Security Alert Vendor Guide This document outlines the procedure and responsibility required for a Vendor to comply with the "Responsible Vulnerability Disclosure Process" proposed by the Internet Engineering Task Force (IETF). SPI Labs has adopted the process and is an active Reporter and/ or Coordinator of security vulnerabilities. Parties involved in vulnerability disclosure There are 4 individuals or groups ("Parties") that may be involved during the entire process. The Parties are listed below: Vendor: The Vendor is an individual or organization who provides, develops, or maintains software, hardware, or services, possibly for free. Customer: The Customer is the end user of the software, hardware, or service that may be affected by the vulnerability. Reporter: The Reporter is the individual or organization that informs (or attempts to inform) the Vendor of the vulnerability. Note that the Reporter may not have been the initial discoverer of the problem. Coordinator: The Coordinator is an individual or organization who works with the Reporter and the Vendor to analyze and address the vulnerability. Coordinators are often well-known third parties. The use of Coordinators by other parties is not a requirement. Phases of responsible security vulnerability disclosure The vulnerability disclosure process is made up of 6 phases. One or more of the parties listed above may participate in any given phase. Listed below are the phases: 1 ­ Discovery Phase: One or more individuals or organizations discover the flaw through casual evaluation, by accident, or as a result of focused analysis and testing. In some cases, knowledge of the flaw may be kept within a particular group. A vulnerability report or an exploit program may be discovered "in the wild," i.e., in use by malicious attackers or made available for use and distribution. 2 ­ Notification Phase: A Reporter or Coordinator notifies the Vendor of the vulnerability ("Initial Notification"). In turn, the Vendor provides the Reporter or Coordinator with assurances that the notification was received ("Vendor Receipt"). 3 ­ Validation Phase: The Vendor or other parties verify and validate the Reporter's claims ("Reproduction"). 115 Perimeter Center Place, Suite 270, Atlanta, GA 30346 (t) 678.781.4800 (f) 678.781.4850 www.spidynamics.com 4 ­ Resolution Phase: The Vendor and other parties also try to identify where the flaw resides ("Diagnosis"). The Vendor develops a patch or workaround that eliminates or reduces the risk of the vulnerability ("Fix Development"). The patch is then tested by other parties (such as a Reporter or Coordinator) to ensure that the flaw has been corrected ("Patch Testing"). 5 ­ Release Phase: The Vendor, Coordinator, and/ or Reporter release the information about the vulnerability, along with its resolution. The Vendor may initially release this information to its customers and other organizations with which it may have special relationships ("Limited Release"). The Vendor or other parties may then release the information ­ possibly with additional details ­ to the security community. 6 ­ Follow-up Phase: The Vendor, Customer, Coordinator, Reporter, or security community may conduct additional analysis of the vulnerability or the quality of its resolution. Vendor Responsibilities In order to facilitate the process effectively, during each phase the Vendor has the responsibility to follow the procedure outlined below. Discovery Phase 1 ­ The Vendor must make it as easy as possible for Reporters to notify the Vendor of security vulnerabilities. 2 ­ The Vendor should establish a Security Response Capability (SRC) that consists of one or more individuals or groups that are responsible for responding to vulnerability reports, verifying vulnerabilities, releasing bulletins, etc. 3 ­ The Vendor should ensure that its staff knows how to recognize a reported security issue and direct it to the Security Response Capability. 4 ­ If the Vendor can control the email addresses that it uses (e.g., it has its own domain name), then the Vendor should define and publish the "secalert" alias for use in vulnerability notification. Notification Phase 1 ­ The Vendor must notify the Reporter and involved Coordinators that the Vendor has received the notification. 2 ­ The Vendor must provide the Reporter and involved Coordinators with a receipt within 7 business days. 3 ­ If the Vendor's receipt message is automatically generated, then it should include a time period or date by which an individual (or the Security Response 115 Perimeter Center Place, Suite 270, Atlanta, GA 30346 (t) 678.781.4800 (f) 678.781.4850 www.spidynamics.com Capability) will provide follow-up on the reported vulnerability. The time period should not exceed 10 business days. 4 ­ Within 10 business days of initial notification, the Vendor's Security Response Capability should provide a clear response to the Reporter and any involved Coordinators. Validation Phase 1 ­ The Vendor should provide status updates to the Reporter and any involved Coordinators every 7 days. The Vendor may negotiate with the parties for less frequent updates. 2 ­ The Vendor must notify the Reporter and any involved Coordinators when the Vendor is able to reproduce the vulnerability. 3 ­ The Vendor should attempt to resolve the vulnerability within 30 days of initial notification. 4 ­ If the Vendor cannot resolve the vulnerability within 30 days, then the Vendor must provide the Reporter and involved Coordinators with specific reasons why the vulnerability cannot be resolved. 5 ­ If the Vendor is aware of other Vendors that share the same codebase as the affected product, then the Vendor must either (a) notify those Vendors, or (b) notify a Coordinator that other Vendors may be affected by the reported vulnerability. Resolution Phase The "Resolution" of a vulnerability involves action regarding one or more of the following: patch creation recommendation of configuration change design change workaround no action 1 - The Vendor must identify the fundamental nature of the flaw within the source code or in the design of the product ("Diagnosis"). 2 ­ The Vendor must provide a patch, configuration change, or workaround that appropriately reduces or eliminates the risk of the vulnerability ("Fix Development"). 3 ­ The Vendor should request time extensions from the Reporter and involved Coordinators when necessary. 115 Perimeter Center Place, Suite 270, Atlanta, GA 30346 (t) 678.781.4800 (f) 678.781.4850 www.spidynamics.com 4 ­ The Vendor must provide the Reporter and involved Coordinators with all known configuration changes or workarounds that address the vulnerability ("Fix Development"). 5 ­ The Vendor should provide the Reporter and involved Coordinators with any patches ("Patch Testing"). Release Phase 1 ­ The Vendor should communicate with the Reporter and involved Coordinators to arrange a date after which the vulnerability information may be released. 2 ­ The Vendor may ask the Reporter and Coordinator to allow a "Grace Period" of up to 30 days, during which the Reporter and Coordinator do not release details of the vulnerability in order not to provide information to hackers, thereby making it easier for them to create exploit programs. 3 ­ If the Reporter has not properly followed the process and publicly announces the vulnerability, then the Vendor should post its awareness of the vulnerability, and the Vendor's progress in its resolution, to appropriate forums. 4 ­ If a Reporter has properly followed the process, then the Vendor must provide credit to that Reporter. 5 ­ The Vendor must not assume that the lack of vulnerability details will prevent the creation of an exploit. Follow-up Phase 1 ­ The Vendor should clearly notify customers and the security community when a resolution is (a) faulty, or (b) revised. Copyright © The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without any restrictions of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. 115 Perimeter Center Place, Suite 270, Atlanta, GA 30346 (t) 678.781.4800 (f) 678.781.4850 www.spidynamics.com