Vulnerabilities / Threats
3/22/2016
10:45 AM
Kymberlee Price
Kymberlee Price
Commentary
Connect Directly
Facebook
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
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.
cjnonsense
50%
50%
cjnonsense,
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.
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Security Technologies to Watch in 2017
Emerging tools and services promise to make a difference this year. Are they on your company's list?
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.