Trustwave is proud to announce an updated vulnerability disclosure policy. In the course of Trustwave's work in information security, we often discover previously unknown vulnerabilities in other vendor's products that pose potential security risks to our customers and the public at large. In these instances we privately disclose the vulnerability to the vendor and work with them with the objective of quickly patching the vulnerability. We believe that this responsible vulnerability disclosure strikes a balance between addressing the public risk and the process necessary to release a high quality patch for the vulnerability.
The full updated policy with highlighted changes follows this blog post.
The 90-Day Deadline
Ninety days should be more than enough time to fix the vast majority of bugs, and it's a deadline Trustwave is adopting as part of our updated disclosure policy. However, if the vendor is responsive, open, and communicative we will be flexible. In our experience working with vulnerability disclosure, there are generally two types of vendors; those that take a couple of days to a couple of weeks to patch a vulnerability, and those that take months or even years to patch. Sometimes sticking to a specific deadline is the only way to light a fire under an organization and actually get them to take the vulnerability seriously.
There's an important reason for these disclosure deadlines. If the "good guys" are finding this vulnerability, there's good reason to think that criminals have found it too or may find it soon. Now this doesn't mean that we won't make an exception in very specific cases. But if there is a reason not to have a fix ready in 90 days, it better contain detailed justification and a new, firm deadline. Our hope, however, is that most vendors will not view the 90-day deadline as the time given to patch, and instead will provide a patch as quickly as possible.
Open Communication
We mention above that if a vendor is responsive and communicative we will be flexible. The importance of keeping an open line of communication during this process can't be stressed enough. Vendors that keep us consistently up to date on their process assures us that they are doing their best to develop a patch. In order to highlight the importance of communication, we've set a 30-day deadline, where if we've had no communication with the vendor we will disclose. However, keeping Trustwave in the loop on a regular and frequent basis will go a long way toward our decision to be flexible with our policy. Vendors that only send us a single email every 30 days in order to keep the clock running are generally not putting forward a best effort in developing a patch. These are typically the same vendors that are always in need of non-stop extensions. Under our new policy these non-communicative vendors will no longer be given extensions.
Proof of Concept Code
Trustwave often releases Proof of Concept (PoC) code or a detailed technical explanation of exploitation in conjunction with a vulnerability disclosure. This can cause vendor concern, and we are often asked to delay the release of a PoC or hold it back completely. We added another section to our policy to cover this situation.
For critical issues we may hold back PoC code for up to two weeks after disclosure in order to allow customers some margin for patching. This delay will only occur in the most serious cases because we see the release of PoC code or a technical explanation of exploitation as a critical component of the disclosure process.
Many seem to believe that the release of PoC or "exploit" code only benefits "script kiddies" without the skills to develop exploits themselves. This idea that public exploits only arm criminals is covered rather well by the concept of HD Moore's Law. HD Moore's popular security tool Metasploit often comes under fire with the same criticism. Hopefully most organizations strive to rise above the bar of the threat of the casual attacker or script kiddie.
PoC code actually helps vendors and their customers in a lot of ways. It gives penetration testers and vulnerability auditors the ability to verify that their admins have applied proper patches. It also provides security professionals with logic that helps them create protections against exploitation like IDS/IPS and Yara/AV rules. A deep technical understanding of the vulnerability will also help security admins make better risk decisions for their environments.
PoC code also seems to make threats posed by the vulnerability more "real" in a lot of eyes. Historically we've seen many vulnerabilities that don't even get noticed. With the addition of a PoC, however, the patches seem to magically flow.
Escalated Timeline for Disclosure
Two other additions to our policy handle situations where either another party discloses the vulnerability or we discover that the vulnerability is being actively exploited in the wild. In the first case of a separate third party disclosure, Trustwave will generally consider the vulnerability to be public and will work with the vendor for immediate disclosure. In the second case of active exploitation, we will work with the vendor on an appropriate escalated timeline. That could potentially be less than seven days after the discovery of exploitation if it is being experienced on a widespread and public scale.
If a vulnerability is being actively exploited, then escalated disclosure timelines are necessary to ensure public safety, but, just like with the general 90-day deadline, a hard unwavering line at 7 days may not be flexible enough for every case.
In the end, it's important to be flexible but firm. There is a common saying that bamboo gains its strength through flexibility. While many larger and thicker trees break or uproot in a storm, bamboo bends and is still standing when the winds die down. This concept is often extended as a metaphor to many things and it applies as well to vulnerability disclosure as anything.
We want to work with vendors and give them time to develop quality patches for their bugs, but we also need to balance that with what is in the public's best interest. When we disclose a vulnerability to a vendor we dedicate time and resources at no cost to help make a vendor's products more secure. In exchange we expect vendors to provide a timely patch or workaround. Our disclosure policy outlines these expectations. There's no doubt that we will run into disagreements, but hopefully this new disclosure policy brings a balanced approach that not only helps a vendor make their products more secure but also holds them responsible for patching vulnerabilities in a quick and timely fashion.
Trustwave SpiderLabs Vulnerability Disclosure Policy
all changes marked and/or annotated in red and bold
Policy Definitions (some minor wording changes added)
- The vendor is the individual, group, or company that maintains the software, hardware, or resources that are related to the vulnerability.
- The date of contact is the point in time when Trustwave SpiderLabs initially contacts the vendor about the vulnerability.
- All dates, times, and time zones are relative to location of Trustwave headquarters (Chicago, IL).
- All day counts are calendar.
The goals of this disclosure policy are education and risk reduction: (risk reduction added as a fundamental goal)
- Education of the vendor about the vulnerability and risk reduction through vendor patch or workaround development.
- Education of Trustwave SpiderLabs on how the vendor intends to fix the vulnerability and risk reduction through developing protections in Trustwave products and services.
- Education of the information security community and the public at large about the vulnerability and risk reduction through spreading awareness of a vendor patch / workaround as well as protections and security controls that can prevent exploitation of the vulnerability.
Policy
A. The vendor will be given 14 days from the date of contact for an initial response. Should no contact occur by the end of 14 days, Trustwave SpiderLabs will evaluate the risk to our clients and may decide to disclose the vulnerability to its clients, at a minimum. (deadline for initial contact changed from 5 days to 14)
B. Trustwave SpiderLabs will provide a best effort to honor requests from the vendor for additional information or help in reproducing the vulnerability. This will include providing configuration details and the scenario in which the vulnerability was discovered.
C. The vendor is responsible for providing regular status updates (regarding the resolution of the vulnerability). If the vendor discontinues communication at any stage of the process for more than 30 days after date of contact, Trustwave SpiderLabs will view the vendor as non-responsive and will consider public disclosure. (this section combines previous sections C and F eliminating the 5 day status update requirement)
D. The vendor is encouraged to provide proper credit to Trustwave and to the researcher responsible for discovering the vulnerability. Suggested (minimal) credit would be: "Credit to <researcher name> from the SpiderLabs team at Trustwave for disclosing the vulnerability to <vendor name>."
E. The vendor is encouraged to coordinate a joint public release/disclosure with Trustwave SpiderLabs so that advisories of the vulnerability and resolution can be made available together.
F. The vendor will be given a maximum of 90 days after date of contact to release a patch. After 90 days Trustwave SpiderLabs will consider public disclosure.
G. If a third party publicly discloses the vulnerability during this process, disclosure will be considered to be public and Trustwave SpiderLabs will work with the vendor for immediate disclosure.
H. If the vulnerability is being actively exploited in the wild Trustwave SpiderLabs will work with vendor on an escalated disclosure timeline potentially less than seven days after date of contact if exploitation is experienced on a wide and public scale.
I. Proof of concept code or technical explanation of exploitation of a vulnerability that is rated critical may be withheld for up to 14 days after public disclosure to allow time for organizations to protect themselves.
