As we discussed in the first blog post of this series, Bugcrowd believes that public disclosure of vulnerabilities is a healthy and important part of the vulnerability disclosure process, and encourages organizations and researchers to work together to share information in a coordinated and mutually agreed upon manner. But why? To quote Bruce Schneier,
"Secrecy prevents people from accurately assessing their own risk. Secrecy precludes public debate about security, and inhibits security education that leads to improvements. Secrecy doesn't improve security; it stifles it."
First things first: Timing Matters
Public disclosure of vulnerabilities can occur before a fix is available (full disclosure), or after the vendor has resolved the software flaw (coordinated disclosure). There are many arguments in favor of full disclosure, but more often than not, researchers choose this option when an organization does not fix a vulnerability it in a reasonable timeframe given the severity and impact of the issue. We recognize that unauthorized public disclosure can be a less than ideal experience for organizations and consumers - especially when a fix is not yet available - and have found that most researchers will try to avoid this.
Organizations may fear that public disclosure will result in bad PR, with potentially negative effects on customer confidence in the security of their product. Furthermore, they believe a public disclosure event can act as blood in the water, attracting malicious hackers seeking similar vulnerabilities to exploit. While these are valid concerns, they oftentimes overshadow the benefits of disclosure, for both organizations and researchers.
How organizations can benefit from public disclosure
- Commitment to Customer Protection: Software customers realize that all software has flaws, so demonstrating a professional and effective security response process for handling these flaws can build customer confidence. By accurately informing customers of the vulnerability risks addressed in a software patch and any available workarounds, software vendors help their customers to prioritize their defensive resources and software update schedules effectively.
- How can a software vendor get started in writing their own advisories? OSVDB has published recommendations on how to craft a security advisory for security researchers which can also be used as a template for vendors.
- Building a Relationship with Researcher Community: Vendors who publicly disclose vulnerabilities in partnership with security researchers send a clear message to the security community that they welcome future collaborative disclosures, thereby further improving their product security and quality. Building a healthy trust-based relationship with external researchers helps vendors expand their defensive capabilities.
How researchers benefit from public disclosure
There are many reasons a researcher may want to blog or present at a conference about a vulnerability; a few common ones include:
- Public Risk Advisory: Public disclosure serves to warn consumers and IT Admins of the availability of a fix and the need to patch their software or implement workarounds until patching is possible. Many researchers publish advisories out of a desire to ensure timely patch uptake. This is the same motivation that may lead a researcher to disclose an unpatched vulnerability, if they believe the risk to customers is too great to wait for a fix to be available. Best practices across the industry typically recommend a 45-120 day period of time between initial private vulnerability disclosure to the vendor and public disclosure.
- Education: Many researchers are interested in teaching other fellow researchers about their technique to find the vulnerability, and/or in teaching developers about an error they may want to check for in their own code. Modern defenders use these reports to help identify similar issues before they are externally identified and improve their SDLC tools and processes.
- Professional Development: While many assume researcher ego is the primary reason for disclosure, security researchers have a legitimate desire to establish technical reputation with external credit for work done. This public visibility may result in the researcher having increased access to lucrative professional opportunities including employment and speaking engagements.
What is the top reason for researchers to publicly disclose?— bugcrowd (@Bugcrowd) March 7, 2016
As you can see, the motivations to disclose are not malicious, and are frequently rooted in defensive posture and intentions for the good of the researcher community and security research landscape. Researchers that report vulnerabilities to vendors are simply using their offensive security skills to help defenders improve product security. Bugcrowd encourages vendors to fix reported vulnerabilities promptly based on priority, and then partner with researchers to publicly disclose once the vulnerability has been fixed.
If you shame attack research, you misjudge its contribution. Offense and defense aren’t peers. Defense is offense’s child.— John Lambert (@JohnLaTwC) March 9, 2014
While Bugcrowd believes public disclosure to be an important part of the vulnerability reporting ecosystem, we support our customers’ individual disclosure policies as outlined in the previous post in this series.
Project Zero: http://googleprojectzero.blogspot.com/2015/02/feedback-and-data-driven-updates-to.html