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.

Risk

7/16/2013
07:22 AM
Dark Reading
Dark Reading
Quick Hits
50%
50%

The Security Pro's Guide To Responsible Vulnerability Disclosure

A look at the changing nature of vulnerability disclosure -- and how it may affect your enterprise defenses

[The following is excerpted from "The Security Pro's Guide to Responsible Vulnerability Disclosure," a new report posted this week on Dark Reading's Vulnerabilities and Threats Tech Center.]

Since the early days of "ethical hacking" and security vulnerability analysis, researchers have followed a time-honored set of rules and traditions as to how to reveal the vulnerabilities they discover in a way that gives the bad guys as small a window as possible to exploit potential security holes in systems and software.

With the advent of "bug bounties" and offers from cybercriminals and government agencies, however, a new vulnerability today has a higher price than ever before.

When it comes to the hot-button topic of vulnerability research and disclosure, there are so many competing interests and attitudes toward doing it properly that it's difficult to know when to speak up and when to shut up. Vulnerability discovery and disclosure can also be a dangerous game from both a moral and a legal perspective.

Further complicating matters is the amount of money involved in vulnerability research. Cybercriminals make their living by buying, selling and exploiting unpatched vulnerabilities, and you'll find no shortage of buyers if you have a novel exploit for sale. Indeed, government agencies will pay handsomely for unique, undiscovered flaws in certain software packages.

This activity has been going on for a long time, but what's changed during the past several years is that commercial software developers are now buyers in this game, and that's what makes the business of vulnerability disclosure so interesting.

It wasn't all that long ago that most software shops unleashed huge armies of lawyers against an organization or individual that threatened to release information about an unpatched vulnerability to the public. The net effect of that approach was that newly discovered vulnerabilities would either go unreported out of fear of retribution or be sold to black market elements. Or they would simply be released to everyone at the same time, including hackers.

Thankfully, forward-thinking software companies have started to evolve their views on the subject of vulnerability disclosure, driven in no small part by open market forces. As a result, companies like Microsoft, Google and Facebook openly pay bug bounties for various undiscovered vulnerabilities. At the same time, bug bounty programs promise to shield security researchers from potential litigation when a vulnerability is reported in a "responsible" manner.

In some cases, the responsible reporting of a new vulnerability can earn you bragging rights and glory in the security business. For example, Google maintains a Hall of Fame that records and recognizes the individual contributions made by security researchers.

By turning the game of vulnerability discovery and reporting into a business that encourages and rewards security pros who come forward and report problems, everyone who plays by the rules benefits.

Unfortunately, not every software company believes in the concept of responsible disclosure. Some say they do, but then bury vulnerabilities in the software equivalent of Hangar 18.

The changing landscape of vulnerability disclosure may affect the way you deploy and manage your defenses. How should you respond to a new vulnerability disclosed in this changing environment? This report offers some insights.

Bug bounty programs have attracted the attention of both hobbyists and professional security pros. Professional security researchers (white-hat hackers) have always helped software companies address vulnerabilities in their code, but now black-hat hackers are getting in on the action -- in a sanctioned way -- as well.

The bug bounty concept is brilliant for several reasons. First, it gives black-hat hackers who would normally sell exploits to criminal elements a way to get paid and recognized -- legally.

Second, software companies gain access to security expertise that they would otherwise have to pay much more for. Third, bug bounty programs allow software companies to develop relationships with security pros, stay on top of trends, get new deas about secure coding standards and recruit top talent without ever having to lift a finger.

Finally, such programs may result in more exploits being uncovered, resulting in your company's computing infrastructure being more secure (assuming that you apply patches for all of these newfound bugs).

Google and Facebook were among the first software companies to challenge the conventional wisdom of vulnerability disclosure by offering financial rewards in exchange for meaningful exploit samples.

Early on, bug bounty programs were viewed as a gimmick by black-hat hackers and white-hat security pros alike. But as time has gone on, these programs have become widely accepted as an effective way to ensure that the most damaging exploits land in the hands of the developer and not the cybercriminal.

To learn more about the process of vulnerability disclosure, how it's changing, and how it may affect your defenses, download the free report.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Edge-DRsplash-10-edge-articles
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
News
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
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
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-27132
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
CVE-2021-25284
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
CVE-2021-3144
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
CVE-2021-3148
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
CVE-2021-3151
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...