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.

Threat Intelligence

1/5/2017
09:00 AM
Marc Laliberte
Marc Laliberte
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

A Look Inside Responsible Vulnerability Disclosure

It's time for security researchers and vendors to agree on a standard responsible disclosure timeline.

Animal Man, Dolphin, Rip Hunter, Dane Dorrance, the Ray. Ring any bells? Probably not, but these characters fought fictitious battles on the pages of DC Comics in the 1940s, '50s, and '60s. As part of the Forgotten Heroes series, they were opposed by the likes of Atom-Master, Enchantress, Ultivac, and other Forgotten Villains.

Cool names aside, the idea of forgotten heroes seems apropos at a time when high-profile cybersecurity incidents continue to rock the headlines and black hats bask in veiled glory. But what about the good guys? What about the white hats, these forgotten heroes? For every cybercriminal looking to make a quick buck exploiting or selling a zero-day vulnerability, there's a white hat reporting the same vulnerabilities directly to the manufacturers. Their goal is to expose dangerous exploits, keep users protected, and perhaps receive a little well-earned glory for themselves along the way. This process is called "responsible disclosure."

Although responsible disclosure has been going on for years, there's no formal industry standard for reporting vulnerabilities. However, most responsible disclosures follow the same basic steps. First, the researcher identifies a security vulnerability and its potential impact. During this step, the researcher documents the location of the vulnerability using screenshots or pieces of code. They may also create a repeatable proof-of-concept attack to help the vendor find and test a resolution.

Next, the researcher creates a vulnerability advisory report including a detailed description of the vulnerability, supporting evidence, and a full disclosure timeline. The researcher submits this report to the vendor using the most secure means possible, usually as an email encrypted with the vendor's public PGP key. Most vendors reserve the [email protected]endorname.com email alias for security advisory submissions, but it could differ depending on the organization.

After submitting the advisory to the vendor, the researcher typically allows the vendor a reasonable amount of time to investigate and fix the exploit, per the advisory full disclosure timeline. Finally, once a patch is available or the disclosure timeline (including any extensions) has elapsed, the researcher publishes a full disclosure analysis of the vulnerability. This full disclosure analysis includes a detailed explanation of the vulnerability, its impact, and the resolution or mitigation steps. For example, see this full disclosure analysis of a cross-site scripting vulnerability in Yahoo Mail by researcher Jouko Pynnönen.

How Much Time?
Security researchers haven't reached a consensus on exactly what "a reasonable amount of time" means to allow a vendor to fix a vulnerability before full public disclosure. Google recommends 60 days for a fix or public disclosure of critical security vulnerabilities, and an even shorter seven days for critical vulnerabilities under active exploitation. HackerOne, a platform for vulnerability and bug bounty programs, defaults to a 30-day disclosure period, which can be extended to 180 days as a last resort. Other security researchers, such as myself, opt for 60 days with the possibility of extensions if a good-faith effort is being made to patch the issue.

I believe that full disclosure of security vulnerabilities benefits the industry as a whole and ultimately serves to protect consumers. In the early 2000s, before full disclosure and responsible disclosure were the norm, vendors had incentives to hide and downplay security issues to avoid PR problems instead of working to fix the issues immediately. While vendors attempted to hide the issues, bad guys were exploiting these same vulnerabilities against unprotected consumers and businesses. With full disclosure, even if a patch for the issue is unavailable, consumers have the same knowledge as the attackers and can defend themselves with workarounds and other mitigation techniques. As security expert Bruce Schneier puts it, full disclosure of security vulnerabilities is "a damned good idea."

I've been on both ends of the responsible disclosure process, as a security researcher reporting issues to third-party vendors and as an employee receiving vulnerability reports for my employer's own products. I can comfortably say responsible disclosure is mutually beneficial to all parties involved. Vendors get a chance to resolve security issues they may otherwise have been unaware of, and security researchers can increase public awareness of different attack methods and make a name for themselves by publishing their findings.

My one frustration as a security researcher is that the industry lacks a standard responsible disclosure timeline. We already have a widely accepted system for ranking the severity of vulnerabilities in the form of the Common Vulnerability Scoring System (CVSS). Perhaps it's time to agree on responsible disclosure time periods based on CVSS scores?

Even without an industry standard for responsible disclosure timelines, I would call for all technology vendors to fully cooperate with security researchers. While working together, vendors should be allowed a reasonable amount of time to resolve security issues and white-hat hackers should be supported and recognized for their continued efforts to improve security for consumers. If you're a comic book fan, then you'll know even a vigilante can be a forgotten hero. 

Related Content:

Marc Laliberte is a senior security analyst at WatchGuard Technologies. Specializing in networking security protocols and Internet of Things technologies, Marc's day-to-day responsibilities include researching and reporting on the latest information security threats and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
tfdj
50%
50%
tfdj,
User Rank: Apprentice
1/9/2017 | 11:01:53 AM
Responsible Disclosure

Great post!  

 

I too am all for having an industry accepted timetable that is adopted not only by the security community, but the business community as well.  Having guidelines that are agreed to by both parties not only ensures that vulnerability fixes are given some priority in the corporate world, but also ensures that security researchers know how much time they have to work with when dealing with corporate entities.

 

Cheers,


Tom

6 Small-Business Password Managers
Curtis Franklin Jr., Senior Editor at Dark Reading,  11/8/2019
Microsoft Tools Focus on Insider Risk, Data Protection at Ignite 2019
Kelly Sheridan, Staff Editor, Dark Reading,  11/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Dueling Free Throws A riff on the song Dueling Banjos
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprise
Assessing Cybersecurity Risk in Today's Enterprise
Security leaders are struggling to understand their organizations risk exposure. While many are confident in their security strategies and processes, theyre also more concerned than ever about getting breached. Download this report today and get insights on how today's enterprises assess and perceive the risks they face in 2019!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-18862
PUBLISHED: 2019-11-11
maidag in GNU Mailutils before 3.8 is installed setuid and allows local privilege escalation in the url mode.
CVE-2019-18853
PUBLISHED: 2019-11-11
ImageMagick before 7.0.9-0 allows remote attackers to cause a denial of service because XML_PARSE_HUGE is not properly restricted in coders/svg.c, related to SVG and libxml2.
CVE-2019-18854
PUBLISHED: 2019-11-11
A Denial Of Service vulnerability exists in the safe-svg (aka Safe SVG) plugin through 1.9.4 for WordPress, related to unlimited recursion for a '<use ... xlink:href="#identifier">' substring.
CVE-2019-18855
PUBLISHED: 2019-11-11
A Denial Of Service vulnerability exists in the safe-svg (aka Safe SVG) plugin through 1.9.4 for WordPress, related to potentially unwanted elements or attributes.
CVE-2019-18856
PUBLISHED: 2019-11-11
A Denial Of Service vulnerability exists in the SVG Sanitizer module through 8.x-1.0-alpha1 for Drupal because access to external resources with an SVG use element is mishandled.