| Anchor |
|---|
| Quote_Bill_Joy_smartest_people |
|---|
| Quote_Bill_Joy_smartest_people |
|---|
|
No matter who you are, most of the smartest people work for someone else. – Bill Joy, Sun Microsystems| Anchor |
|---|
| Receive_Reports_ |
|---|
| Receive_Reports_ |
|---|
|
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.
| Anchor |
|---|
| Create_Secure_Channels_for_Rep |
|---|
| Create_Secure_Channels_for_Rep |
|---|
|
| Anchor |
|---|
| _Toc479938859 |
|---|
| _Toc479938859 |
|---|
|
| Anchor |
|---|
| _Toc489873187 |
|---|
| _Toc489873187 |
|---|
|
Create Secure Channels for Reporting| Anchor |
|---|
| Create_Secure_Channels_for_Rep-1 |
|---|
| Create_Secure_Channels_for_Rep-1 |
|---|
|
Whether you are a vendor or a coordinator, you need to have open channels for communication with vulnerability finders and reporters. In our experience, the most common means of communication is email. 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.
However, 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.
Alternatively, 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. 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.
Another possibility is to make use of a third-party bug bounty or coordination platform. For more information on common CVD tools, see Section 7.
| Anchor |
|---|
| Encourage_Reporting |
|---|
| Encourage_Reporting |
|---|
|
| Anchor |
|---|
| _Toc479938860 |
|---|
| _Toc479938860 |
|---|
|
| Anchor |
|---|
| _Toc489873188 |
|---|
| _Toc489873188 |
|---|
|
Encourage Reporting| Anchor |
|---|
| Encourage_Reporting_1 |
|---|
| Encourage_Reporting_1 |
|---|
|
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.
| Anchor |
|---|
| Encourage_Reporting_ |
|---|
| Encourage_Reporting_ |
|---|
|
Aside from the technical aspects of encouraging reporting, vendors can also provide reporters with other incentives, as discussed in Section 2.4.
| Anchor |
|---|
| Reduce_Friction_in_the_Reporti |
|---|
| Reduce_Friction_in_the_Reporti |
|---|
|
| Anchor |
|---|
| _Toc479938861 |
|---|
| _Toc479938861 |
|---|
|
| Anchor |
|---|
| _Toc489873189 |
|---|
| _Toc489873189 |
|---|
|
Reduce Friction in the Reporting Process| Anchor |
|---|
| Reduce_Friction_in_the_Reporti-1 |
|---|
| Reduce_Friction_in_the_Reporti-1 |
|---|
|
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
| Anchor |
|---|
| Providing_Useful_Information |
|---|
| Providing_Useful_Information |
|---|
|
| Anchor |
|---|
| _Toc479938862 |
|---|
| _Toc479938862 |
|---|
|
| Anchor |
|---|
| _Toc489873190 |
|---|
| _Toc489873190 |
|---|
|
Providing Useful Information| Anchor |
|---|
| Providing_Useful_Information_ |
|---|
| Providing_Useful_Information_ |
|---|
|
Reporting a vulnerability requires that the vulnerability is well-documented. This typically means providing 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 or remediation action if the reporter is aware of how to fix the vulnerability
| Wiki Markup |
|---|
description of the impact of the vulnerability and attack scenario (Kymberlee Price discusses the importance of providing a clear attack scenario in her article \[76\].) |
- any time constraints (for example, give a date of publication or presentation at a conference if you know)
| Wiki Markup |
|---|
Reporters that do not provide enough information to a vendor or coordinator may find their reports delayed or even rejected. Using CWE \[77\] or CAPEC \[78\] as a reference might be helpful to describe the type of vulnerability you have found and common ways to fix it the problem
An example of a template for a vulnerability report, based on the CERT/CC's own Vulnerability Reporting Form (VRF) \[79\], is provided in Appendix D.
Vendors that require additional information to validate reports should clearly document their specific requirements in their vulnerability disclosure policy, reporting form, or process description. |
