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.
Facebook Aims to Make Security More Social
Kelly Sheridan, Associate Editor, Dark Reading,  2/20/2018
SEC: Companies Must Disclose More Info on Cybersecurity Attacks & Risks
Kelly Jackson Higgins, Executive Editor at Dark Reading,  2/22/2018
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
How to Cope with the IT Security Skills Shortage
Most enterprises don't have all the in-house skills they need to meet the rising threat from online attackers. Here are some tips on ways to beat the shortage.
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.