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

Recommended Reading:

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.
FluBot Malware's Rapid Spread May Soon Hit US Phones
Kelly Sheridan, Staff Editor, Dark Reading,  4/28/2021
7 Modern-Day Cybersecurity Realities
Steve Zurier, Contributing Writer,  4/30/2021
How to Secure Employees' Home Wi-Fi Networks
Bert Kashyap, CEO and Co-Founder at SecureW2,  4/28/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-07
An issue was discovered on Tenda AC11 devices with firmware through A stack buffer overflow vulnerability in /goform/setmac allows attackers to execute arbitrary code on the system via a crafted post request.
PUBLISHED: 2021-05-07
An issue was discovered on Tenda AC11 devices with firmware through A stack buffer overflow vulnerability in /gofrom/setwanType allows attackers to execute arbitrary code on the system via a crafted post request. This occurs when input vector controlled by malicious attack get copie...
PUBLISHED: 2021-05-07
An issue was discovered on Tenda AC11 devices with firmware through A stack buffer overflow vulnerability in /goform/setVLAN allows attackers to execute arbitrary code on the system via a crafted post request.
PUBLISHED: 2021-05-07
An issue was discovered on Tenda AC11 devices with firmware through A stack buffer overflow vulnerability in /goform/setportList allows attackers to execute arbitrary code on the system via a crafted post request.
PUBLISHED: 2021-05-07
This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Reader User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handlin...