Bug Bounty Programs comes to Website Security: What do they mean?
Recently I tweeted a passing thought, "I wonder if the final stage of maturity for website vulnerability management is offering a bug bounty program." This was stimulated by the news that Mozilla became the second company, following Google, to provide monetary rewards for security researches who find and privately report website vulnerabilities. Only last year this idea would have been considered crazy. Sure, other organizations including Microsoft, Facebook, and PayPal already gladly accept third-party vulnerability disclosures without threatening legal action, but it�s the financial compensation part that sets Google and Mozilla apart.
I�m sure others like myself in the community are asking if website vulnerability bug bounty programs a good idea to begin with and if such programs an anomaly or the start of a 2011 trend?
If we posed the first question to bug hunting masters Charlie Miller, Alex Sotirov, and Dino Dai Zovi there is no question how they�d answer. "No More Free Bugs." Not that all researchers must ascribe to this philosophy, it�s a personal choice, but there certainly shouldn�t be a stigma attached to those who do. The thing is the bugs these gentlemen generally focus on reside in desktop-based software developed by large ISVs. Software that can be readily tested in the safe confines of ones own computer where permission is not strictly required. Website vulnerabilities are in a word, different.
Website vulnerabilities reside in the midst of a live online business, on someone else�s network, where penetration-testing without permission is illegal and the results of which may cause degraded performance and downtime. Not that legalities ever really got in the way of a free pen-test. See the thousands of public cross-site scripting disclosures on XSSed.com. Still, I�d personally agree that while bug bounty programs can indeed be a good idea for a certain class of website owner, I think everyone would recommend thoughtful consideration before opening up the hack-me-for-cash flood gates.
What�s most interesting to me is understanding why Google and Mozilla themselves believe they need a bug bounty program the first place. It�s not like Google and Mozilla don�t invest in application security or would depend on such an initiative. In fact, from my personal interactions their level of application security awareness is top notch and practices represent among the most mature across the Web. They invest in source code reviews, security QA testing, penetrating tests / scans conducted by insiders and third-parties, developer training, standardized development constructs, threat modeling, and a collection of other Software Security Assurance (SSA) related activities. Activities most organization are still coming up to speed on.
So Google and Mozilla have already done essentially all our industry "recommends." Yet, as the multitude of negative headlines and unpaid vulnerabilities disclosures historically show, issues are still found by outsiders with annoying regularity. Personally I think that�s where the motivation for a bug bounty program comes from.
Google and Mozilla probably view their bounty programs as a way to remove additional missed bugs from the vulnerabilities pool, remediate them in a manageable way, foster community good will, and for the low low price of few hundred to a few thousand bucks. Check it out. In the first two months of Google�s program, it looks like they�ve paid out a few 10s of thousands of dollars to three dozen or so researchers. Said another way, the PR benefit is perhaps three dozen user confidence shaking news stories DIDN'T get published. All in all for that price, suddenly the idea of paying "the hackers" doesn�t sound as crazy.
It should be made crystal-clear that bug bounty programs are in no way a replacement for any part of an SSA or an SDL program, rather they are complementary and an opportunity to facilitate improvement. Also, bug bounty programs are not for everybody, and probably not even for most. Only those organizations that truly have their application security act together should even consider offering such a program.
For example, the organization should already have reasonably bug free websites or they won't offering attractively priced bounties for long. Budgets would run out fast and they�ll be forced to suspend the program, which would be quite embarrassing. The organization must also have a strong process in place to receive, validate, respond, act upon, and pay out for submissions. Next as Mike Bailey, a self proclaimed Narcissistic Vulnerability Pimp elegantly stated, "bounty program also involves an implicit commitment to fix bugs quickly." That�s right, no sitting on bugs for a "reasonable" amount of time -- like months to a year or more. Finally the organization will require a super-stable infrastructure capable of enduring sustained attack by hundred or perhaps thousands of entities.
In my humble opinion if an organization has all of this in place, then I�m confident in saying there is a correlation between bug bounty programs and website vulnerability management / SSA maturity.
Jeff Moss, the man behind Black Hat and Defcon, recently encouraged Microsoft, a firm long opposed paying for bugs, to offer a bounty program. "I think it is time Microsoft seriously consider a bug bounty program. They advanced the SDL, it is time for them to advance bounties." I�ve suggested the very same to Microsoft in person on more than one occasion. Veracode has that as a 2011 infosec prediction. Everyone I know of has received a response similar to the following:
"We do not believe that offering compensation for vulnerability information is the best way we can help protect our customers." - Dave Forstrom, group manager of Microsoft Trustworthy Computing.
And there you have it. Is the website vulnerability bounty program phenomena the start of a trend? Who can really say? Only time will tell.
