Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10:45 AM
Kymberlee Price
Kymberlee Price
Connect Directly
E-Mail vvv

Vuln Disclosure: Why Security Vendors & Researchers Dont 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.

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.  


Related Content:

Interop 2016 Las VegasFind out more about security threats at Interop 2016, May 2-6, at the Mandalay Bay Convention Center, Las Vegas. Register today and receive an early bird discount of $200.

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 ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
Joe Stanganelli,
User Rank: Ninja
3/31/2016 | 11:18:22 AM
So much for cooperation in security
Reminds me of when Google engineer Tavis Ormandy released a zero-day Microsoft vulnerability before Microsoft had the opportunity to patch it -- and the stark contrast that action and Google's nonchalant response to it bore to the Microsoft Vulnerability Research program.
User Rank: Apprentice
3/24/2016 | 10:01:06 AM
Order of steps
I was very taken by the 'good sense' communicated in this article. My only comment is that for this 5 step approach to really work, the 'BE' steps must come first. In other words, each side must BE trustworthy and each side must BE transparent. Otherwise, the other three steps will never happen.

The root to all of this is humility. If you've lived in any facet of IT for any length of time, you should realize that you cannot and will not ever know it all! It is an impossible task. Openly admitting that to yourself and verbalizing that to anyone else will lead to both trustworthiness and transparency.

The remaining steps could be summarized as seek first to understand and then seek to be understood. Of course, these things all run counter to our natural sense of self protection. Particularly, the protection of our ego(s).

As is so often the case, we are our own worst enemies.
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Exploits Released for As-Yet Unpatched Critical Citrix Flaw
Jai Vijayan, Contributing Writer,  1/13/2020
Microsoft to Officially End Support for Windows 7, Server 2008
Kelly Sheridan, Staff Editor, Dark Reading,  1/13/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
[Just Released] How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-01-18
A memory usage vulnerability exists in Trend Micro Password Manager 3.8 that could allow an attacker with access and permissions to the victim's memory processes to extract sensitive information.
PUBLISHED: 2020-01-18
A RootCA vulnerability found in Trend Micro Password Manager for Windows and macOS exists where the localhost.key of RootCA.crt might be improperly accessed by an unauthorized party and could be used to create malicious self-signed SSL certificates, allowing an attacker to misdirect a user to phishi...
PUBLISHED: 2020-01-18
An arbitrary code execution vulnerability exists in the Trend Micro Security 2019 (v15) consumer family of products which could allow an attacker to gain elevated privileges and tamper with protected services by disabling or otherwise preventing them to start. An attacker must already have administr...
PUBLISHED: 2020-01-18
A Persistent Arbitrary Code Execution vulnerability exists in the Trend Micro Security 2020 (v160 and 2019 (v15) consumer familiy of products which could potentially allow an attacker the ability to create a malicious program to escalate privileges and attain persistence on a vulnerable system.
PUBLISHED: 2020-01-18
An issue was discovered in Amcrest Web Server 2.520.AC00.18.R 2017-06-29 WEB The login page responds with JavaScript when one tries to authenticate. An attacker who changes the result parameter (to true) in this JavaScript code can bypass authentication and achieve limited privileges (...