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] 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
 

Recommended Reading:

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

Commentary
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
Edge-DRsplash-10-edge-articles
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
News
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
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
CVE-2021-32716
PUBLISHED: 2021-06-24
Shopware is an open source eCommerce platform. In versions prior to 6.4.1.1 the admin api has exposed some internal hidden fields when an association has been loaded with a to many reference. Users are recommend to update to version 6.4.1.1. You can get the update to 6.4.1.1 regularly via the Auto-U...
CVE-2021-32717
PUBLISHED: 2021-06-24
Shopware is an open source eCommerce platform. In versions prior to 6.4.1.1 private files publicly accessible with Cloud Storage providers when the hashed URL is known. Users are recommend to first change their configuration to set the correct visibility according to the documentation. The visibilit...
CVE-2021-32712
PUBLISHED: 2021-06-24
Shopware is an open source eCommerce platform. Versions prior to 5.6.10 are vulnerable to system information leakage in error handling. Users are recommend to update to version 5.6.10. You can get the update to 5.6.10 regularly via the Auto-Updater or directly via the download overview.
CVE-2021-32713
PUBLISHED: 2021-06-24
Shopware is an open source eCommerce platform. Versions prior to 5.6.10 suffer from an authenticated stored XSS in administration vulnerability. Users are recommend to update to the version 5.6.10. You can get the update to 5.6.10 regularly via the Auto-Updater or directly via the download overview.
CVE-2021-32710
PUBLISHED: 2021-06-24
Shopware is an open source eCommerce platform. Potential session hijacking of store customers in versions below 6.3.5.2. We recommend to update to the current version 6.3.5.2. You can get the update to 6.3.5.2 regularly via the Auto-Updater or directly via the download overview. For older versions o...