Slashdot Mirror
Is Paying Hackers Good for Business?
Jenny writes "In the light of the recent QuickTime vulnerability, revealed for $10,000 spot cash, the UK IT Security Journalist of the Year asks why business treats security research like a big money TV game show. 'There can be no doubt that any kind of public vulnerability research effort will have the opportunity to turn sour, both for the company promoting it and the users of whatever software or service finds itself exposed to attack without any chance to defend itself. Throw a financial reward into the mix and the lure of the hunt, the scent of blood, is going to be too much for all but the most responsible of hackers. There really is no incentive to report their findings to the vulnerable company, and plenty not to. Which is why, especially in the IT security business, there needs to be a code of conduct with regard to responsible disclosure.' Do you think there's any truth to this? Or is it a better idea to find the vulnerabilities as fast as possible, damn the consequences?"
0-Day exploits are already big business on the black market, better for the companies to pay for disclosure and have a more secure product, than for the exploits to be sold off on the black market and only discovered after a significant portion of the user base has been compromised.
Curiosity was framed, Ignorance killed the cat.
Is why would such contests HAVE to report what vulnerability successfully got through. Shouldnt the results be between the company holding the contest, the successful hacker, and companies whose software was involved in the vulnerabilities be the only ones who know?
Why couldn't one just announce "Joe Bob McHobo was the winner!" without publicizing the vulnerability itself before the softwares author gets a crack at it.
Humanity is weird.
Ice Cream has no bones.
'Responsible disclosure' is a euphemism for 'we can't fix bugs fast enough, so if you keep the vulnerabilities a secret, it'll help us to save face.' And more time often means months, not days. Responsible disclosure is nothing more than security through obscurity. And security through obscurity is as good as no security at all. In the intervening months, you have a live, exploitable hole sitting there ripe for attack! And not just on that one system -- every like-configured system is vulnerable. I say, damn the consequences. Report as soon as possible no matter who it embarrasses. It'll either put more pressure on them to fix the bugs faster, or push users to more secure platforms, where security fixes don't take months and are usually found before their ever exploited in the wild.
My blog
why business treats security research like a big money TV game show
Maybe because the bugs they find are "showstoppers"?
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
The problem with your analogy is that "bounty hunters" in the infosec debate would actually be searching for the exploiters, not the exploits.
Wow. How is it that an "ex-hacker" who now "specialises in security from the white hat side of the fence" (from the author's bio) can have so little clue about the responsible disclosure debate and the economics of modern vulnerability research? Maybe getting lambasted on Slashdot will be a wake-up call for him to actually do his homework before he spouts off.
Better to light a candle than to curse the darkness.
Nice way to take the situation out of context with the snippet here on /. I think the important question isn't whether public, for-pay security hunting is a good idea, but rather if it's ethical for an outside firm to pay for it. Would anyone have batted an eye if Apple had been the one advertising for a hack for the Mac? I don't think so, they'd probably have been lauded for having the wherewithal to offer good money to people to help them find exploits of their software.
Which is why, especially in the IT security business, there needs to be a code of conduct with regard to responsible disclosure.' Do you think there's any truth to this? Or is it a better idea to find the vulnerabilities as fast as possible, damn the consequences?"
Considering how quickly companies tend to SUE you for disclosing a vulnerability, I don't think there can be any true code of conduct between hackers and companies.. Not unless the companies start making it (public) policy that they WILL NOT sue you as long as you disclose a vulnerability to them first, and give them a reasonable time to fix it before going public.
I think that'll never happen though, and the only way to safeguard a hacker is to make legislation against those type of lawsuits.
I also think that'll never happen either, considering how firmly planted the lips of those companies are to the politician's ass... So *#@& 'em, we just need a good way to disclose anonymously.
-- If we don't stand up for our rights, now, there will be no right to stand up for them later.
They released a product with security holes in it, they should pay to have them found.
If a construction company builds a bridge with defects that causes it to fall on someone, that someone can sue them.
If a software company makes an insecure product, and someone gets pwned because of it, that should be allowed to sue for damages.
Yes security holes aren't easy to find in big products, but it should never be an excuse for a company (especially those that make billions, wink wink) for them to release unsafe products.
I am a security analyst by profession and education [not that it matters, but as a distinction of the previous poster's non-security background].
... there are vast categories of vulnerabilities that end up compiled in code unnecessarily. And a great place to start for anyone looking to weed these unforgiveable buffer overrun types of issues out of their code is to use a static analyzer on their code. Essentially, static analysis tools attempt to catch these obvious (or sometimes not so obvious) bugs before the code is shipped to customers. Fortify Software is a great place to look for such a tool.
You are somewhat correct. Sloppy coding techniques do lead to security vulnerabilities which lead to exploit code which eventually lead to websites burning, etc. However, that is only one category of security flaws. If you look at, say the GDI flaws Microsoft had last year (for example), you'll notice that vulnerability is actually a design flaw-- allowing executable code to live embedded in file objects was the problem [the embedded code's trustworthiness had no mechanism to be measured and therefore any user double-clicking on a malicious code-within-an-image file would have their system compromised]. Design flaws are much more tricky to prevent and most experts attempting to solve this problem suggest that development houses should leave the design aspects of their code to people with a background in security principles, or at least have some sort of design-time security review. This is mostly what formalized threat modeling attempts to do.
But you are right
The problem with your argument is it's much harder to create a secure software product than it is to create a secure bridge. This is especially true because delaying construction of a bridge for a month can be done without competitors swooping in and taking the market.
"Responsible disclosure" would have been great, except that history has shown us that it usually doesn't work. When "responsible disclosure" has been tried the vulnerability has lingered (especially with the larger corporations). When the vulnerability has been openly disclosed, then suddenly the software gets a patch. If history had been different then perhaps we would give the idea consideration. But it wasn't, and it was a problem created by the software companies themselves, so here we are today reaping the seeds that were sown.