Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
Vuln Disclosure: Why Security Vendors & Researchers Don’t Trust Each Other
The security industry doesn’t need a one-size-fits all vulnerability disclosure policy. It needs a culture change. Getting everyone to the table is the first step.
March 22, 2016
5 Min Read
Over the last 15 years there have been multiple vulnerability disclosure policies written by individuals, companies, and cross-industry working groups. They are all well-thought out by intelligent people yet each of these policies has failed – primarily because none of them are used in a meaningfully, consistent way; every vendor defines its own policy, and security researchers are powerless to enforce any of the policies if a vendor chooses not to follow them.
This is no accident. It’s because the security ecosystem is too complex for any single policy to be both supported and followed by the majority of vendors and researchers. In fact, both parties complain about the same things:
“It doesn’t fit my business model.”Every vendor has a valid argument, whether it’s around technology, security maturity or resources. Researchers have similar arguments based on their assessment of risk, business impact, or professional disclosure.
“It doesn’t represent all sides fairly.” Most policies were written either by researchers or vendors, inevitably leaving a portion of the industry feeling disenfranchised. One of the most obvious examples of how this impacts disclosure policies is in time-to-fix parameters. Policies written by researchers have relatively firm public disclosure deadlines, while vendor-written policies tend to be a lot looser about timelines to fix an issue.
“I don’t trust the other party.” Vendors don’t trust researchers, and researchers don’t trust vendors. This distrust is a result of many years of “us vs. them” hostility and a lack of respect, open communication, and understanding.
There are two primary reasons why defenders are pitted against each other and unable to define an industry standard disclosure policy. First, we as an industry and ecosystem can’t agree on the need and effectiveness of policy. Second, we can’t enforce trust on either side of the vendor/researcher relationship with a policy because there is no escalation path for disputes. Today’s practice of public shaming isn't working for anyone.
So, instead of oversimplifying a highly complex and diverse ecosystem with a one-size-fits-all solution that doesn’t fit anyone well; or waiting for the ‘One Policy to Rule Them All’, I'd like to make five actionable recommendations:
1. Build trust networks. There are many examples of researchers and vendors who do things that critically damaged their ability to work together. Both sides have valid complaints which have created a foundation of distrust that hampers our ability to accomplish a shared goal of improving security to protect customers. How do we learn to establish trust? We need more than meeting in person at conferences a couple of times a year (at best). That simply doesn't scale.
Instead, we need to actively build trust networks with other defenders, and vet new contacts within that network. This can be as straightforward as conducting an Internet search to see someone's behavioral history with vulnerability disclosure, or asking industry peers if they have any experience with your new contact (either a vendor or researcher). We can consciously identify ways to take gradual small risks, share information over time to establish new trust relationships, or get on a videoconference to connect as human beings and overcome the challenges of text-based communication that foster miscommunication and misunderstandings. I'm not suggesting we should blindly trust everyone, but we need to soften the adversarial attitude and remember that we are on the same team.
2. Be transparent. Vendors: Don’t wait for an acceptable industry standard disclosure policy. Publish your disclosure policy now and let researchers know what to expect when they report a vulnerability to you. We get it. You have hundreds of bugs to fix, and each researcher’s precious finding is just one in the priority stack. But unresponsiveness on your part implies a lack of urgency, which reinforces researchers’ beliefs that public disclosure drives engineering effort and gets software fixes shipped. Without the threat of disclosure, researchers believe vendors will drag their feet on patching their software, delaying customer protection.
Researchers: Recognize that not every vendor will have the same engineering practices, resources, or timelines, so their disclosure policies will likely vary, even in established programs. If you think a policy is unreasonable, give thoughtful and respectful feedback with recommendations for improvement, instead of snarking about it in 140-character twitter feeds.
3. Share knowledge. Vendors, once you’ve published your disclosure policy, how about you also share your product security incident response templates and tools with other defenders to help less experienced vendors get started? Others can learn from your experience, and you may gain valuable feedback from the community that can improve your processes and policies.
4. Be trustworthy. Vendors, if a researcher reported a vulnerability to you, give them regular status updates and an ETA on the fix being released. Demonstrate that you appreciate their report and are taking action to protect your customers. Remember, they already know about the vulnerability; if they wanted to hurt your company they wouldn't have reported it to you to begin with. Researchers, don’t burn bridges. This is a long-term relationship for both parties - you are a critical part of working through conflict and "leveling up" the relationship.
Vendors and researchers: Fair or not, remember that your actions reflect on your peers.
5. Join an industry working group. If you're an optimist, you're being part of the solution. If you're a pessimist, come make sure we don't mess it up too badly. It is time to stop being a tourist in the field of disclosure, as the decisions being made directly affect you. Review proposals and provide thoughtful, actionable feedback. I'm co-chair of the NTIA working group on multi-party vulnerability disclosure and we would love to have more researchers and diversity of vendors represented in our group. There are also NTIA working groups on Disclosure Policy Adoption & Awareness, Economic Incentives, and Disclosure and Safety.
We don't need a disclosure policy, we need a culture change. I’ve seen this happen, it IS possible. Getting everyone to the table is the first step.
About the Author(s)
Senior Director of Researcher Operations, Bugcrowd
With over 13 years experience in product security, Kymberlee Price pioneered the first security researcher outreach program in the software industry, was a principal investigator in the Zotob criminal investigation, and analyzed APT's at Microsoft. She then spent 4 years investigating product vulnerabilities in BlackBerry's Security Response Team. Today she is responsible for directing the efforts of Bugcrowd's global red team of more than 25,000 security researchers, optimizing vulnerability discovery and reporting for customers and researchers, and aiding 'the Crowd' with ongoing skill development and overall success in Bugcrowd programs. Ms. Price holds a Bachelor of Science degree in Behavioral Psychology and a Bachelor of Science degree in Public Health Education. She has previously spoken at a number of conferences, including Black Hat USA, RSA, Kaspersky Security Analyst Summit, Metricon, NullCon, and Derbycon.
You May Also Like
Your Everywhere Security guide: Four steps to stop cyberattacksFeb 27, 2024
Your Everywhere Security Guide: 4 Steps to Stop CyberattacksFeb 27, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
API Security: Protecting Your Application's Attack SurfaceFeb 29, 2024
Securing the Software Development Life Cycle from Start to FinishMar 06, 2024
Laptop with ransomware, and bitcoin in the palm of a man's hand to illustrate ransomwareCyberattacks & Data Breaches