Proposed: a Bounty for Bugs

Big Bucks for Big Bugs

  • alert
  • submit to reddit

Choosing a cloud hosting partner with confidence

Instead of paying hard cash to punish computer criminals, vendors should reward grey hat hackers for responsibly finding and reporting the security holes that make cyber attacks possible, argues SecurityFocus columnist Mark Rasch.

Microsoft recently announced a $500,000 bounty for the arrest and prosecution of those responsible for the SoBig and Slammer attacks. This is, in essence, offering to pay money to catch the guys who stole the horse after the barn door is left open. I have another idea: a bounty for security holes, paid to the grey hat hackers who find them.

I'll loosely define grey hat hackers as those who, on their own initiative and without any authorization, discover but do not exploit (well, maybe just a bit to validate the existence) new vulnerabilities in hardware, software, or configurations. If they do this with full knowledge and authorization of the affected company, they are white hats; if they criminally exploit the vulnerabilities, they are black hats.

There are a couple of model protocols for these bug finders to tell vendors about a vulnerability, and for vendors to respond appropriately. Security researcher Rain Forest Puppy wrote one, and the industry group the Organization for Internet Safety has proposed another set of rules for each party to this dance.

What is lacking is an effective mechanism for grey hat hackers to notify vendors, validate that such notice has been received, get credit (and sometimes compensation or remuneration) for the discovery, and verify that the vulnerability has been remediate.

My solution: an ISAC for grey hat hackers.

An ISAC, if you don't know, is an Information Sharing and Analysis Center. This is the mechanism officially promoted by the U.S. and other governments for securely and confidentially sharing vulnerability information within an industry: the IT industry has an ISAC; telecommunications companies have one of their own; banks have a "Financial Services" ISAC. The list goes on.

Of course, none of the ISACs include grey hat hackers on their board of directors, and the organizations decidedly do not serve as a forum for this community to advice organizations about vulnerabilities.

The Grey Hat ISAC would be a semi-confidential hacker board. Grey hats would transmit information -- as detailed as they like -- about any new vulnerability. They could do this either for attribution, anonymously (including using anonymizing technology), or under an established pseudonym.

The information would not be posted to the board, however. The posting would be assigned a tracking number that the bug-finder could follow. Thus, the grey hat would be able to track when the vendor or organization was notified of the vulnerability, and whether they acknowledged receipt. They could get a progress report periodically (weekly? every three days?), and there would be a mechanism for the vendor or organization to contact the grey hat for more information.

Thus, the vendor could post a message tied to the tracking number indicating that they need more information, and the general category of information they need. The operator or the site could help facilitate the communication between grey hat and vendor.

Big Bucks for Big Bugs

The vendor would then notify the grey hat of the results of its inquiry. If the vendor fails to respond adequately (and the rules about what qualified as an "adequate" response would have to be pre-determined), the grey hat would be free to post the information, either to the affected community confidentially, to the site's own board, or to other forums -- depending on the rules developed in establishing the board.

After a predefined time period -- anywhere from 10 days three weeks -- the vulnerability would be publicly disclosed, hopefully together with the vendor's response and a fix. The grey hat would get credit for the discovery.

The whole thing would be funded by the vendors, through cash rewards for serious bugs.

If the vulnerability creates a substantial risk to the vendor, or the product's users, the vendor would pay a bounty for the discovery, in addition to giving the finder proper credit. So, for example, the vendor could pay $6,000 for a vulnerabilitiy, with $1,000 to the operator of the board, and $5,000 to the grey hat's Pay Pal account.

Of course, if the bug-finder committed a crime in the discovery of the vulnerability (e.g., stole internal documents, broke into computers, etc.) he or she would be ineligible for the reward, and would be eligible for free room and board compliments of the Attorney General.

The Grey Hat ISAC would defuse the legal and ethical minefield that these hackers are walking today. Under current law, if they demand compensation in return for telling the vendor of a vulnerability (or for not telling others), they may be guilty of extortion. Moreover, the act of publicly revealing a vulnerability may itself lead to civil and criminal liability. From a moral and ethical standpoint, who appointed these guys as the protectors of the Internet? What right do they have to dictate my priorities in terms of fixing vulnerabilities? Why do I have to amass my security team at 3:00 a.m. on a Sunday because they decided to use that instant to tell the world exactly how to commit an illegal break-in into my network?

Vendors and online businesses are not blameless either. Too often, companies tell their shareholders, consumers, regulators, and business partners that they are secure, and then fail to act on information that would belie these conclusions. When grey hats do try to advise them of new vulnerabilities, these warnings go unheeded -- or at least it appears this way to the grey hats. Configuration problems persist for months or years, making the vendor or user more and more vulnerable to potentially devastating attacks.

There are lots of details that would have to be worked out. But why not have vendors pay the bounty to make themselves more secure, rather than opening their wallet once it's too late? And why not give the grey hats a mechanism to inform the vendors, and at least give them the chance to do the right thing? I think it's worth a shot.

Copyright ©

SecurityFocus columnist Mark D. Rasch, J.D., is a former head of the Justice Department's computer crime unit, and now serves as Senior Vice President and Chief Security Counsel at Solutionary Inc.

Beginner's guide to SSL certificates

More from The Register

next story
FYI: OS X Yosemite's Spotlight tells Apple EVERYTHING you're looking for
It's on by default – didn't you read the small print?
Russian hackers exploit 'Sandworm' bug 'to spy on NATO, EU PCs'
Fix imminent from Microsoft for Vista, Server 2008, other stuff
Microsoft pulls another dodgy patch
Redmond makes a hash of hashing add-on
'LulzSec leader Aush0k' found to be naughty boy not worthy of jail
15 months home detention leaves egg on feds' faces as they grab for more power
Kill off SSL 3.0 NOW: HTTPS savaged by vicious POODLE
Pull it out ASAP, it is SWISS CHEESE
Facebook slurps 'paste sites' for STOLEN passwords, sprinkles on hash and salt
Zuck's ad empire DOESN'T see details in plain text. Phew!
China is ALREADY spying on Apple iCloud users, claims watchdog
Attack harvests users' info at iPhone 6 launch
prev story


Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Cloud and hybrid-cloud data protection for VMware
Learn how quick and easy it is to configure backups and perform restores for VMware environments.
Three 1TB solid state scorchers up for grabs
Big SSDs can be expensive but think big and think free because you could be the lucky winner of one of three 1TB Samsung SSD 840 EVO drives that we’re giving away worth over £300 apiece.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.