By KK Mookhey, Founder, NII Consulting
Over the past few years, bug bounties have begun to garner mainstream attention. With over 150 companies offering their own bug bounty programs and hundreds of others working with the likes of Bugcrowd and HackerOne, it is really no longer a question of whether you should start a bug bounty program or not, but rather when and how you should be running it.
Let’s begin by taking a look at the various possible options:
Running your own program
While this entails a fair amount of effort from within your organization it does give you the advantage of being able to control the entire process more tightly and also keeping your legal and compliance teams satisfied. Plus, it brings you closer to the hacker community and gives you the option of being able to hire some of these talented folks to be part of your security teams full-time.
The following aspects need to be looked at when developing your own bounty program:
All bugs are not equal: Obviously you don’t want to reward all bugs. Some you would like to keep off the list. For instance, if you’re a product company you’d want to discourage bugs found in your corporate websites or internet infrastructure, such as what Meraki does. You also want to exclude ‘cookie not marked as secure’ and ‘logout CSRF’ and other such types of bugs from consideration. See ‘Uber’s’ Bug Bounty page for an excellent way to communicate the rules of the game.
The payout: How do you want to rate the bugs and pay out for them? It could be in actual cash, or it could be some other form of rewards, such as the miles that United Airlines gives out, or it could be simply building a Wall of Fame and recognizing the researchers such as what Apple does. If your organization is a bank you could issue a pre-loaded credit or debit card and then simply keep loading it if the same researcher finds more bugs.
Internal communication: How well have you communicated internally about such a program and the rationale for it, and what benefits could accrue to the organization from such a program. Also, are critical departments such as legal and compliance on board?
Your processes: How will you track the reported bugs, analyse them, weed out false positives and coordinate the remediation with your development teams or vendors.
External communication: Security researchers can be extremely sensitive to a negative response from your team or one that is vague. Also, delayed responses could prompt the researcher to disclose the bug publicly. So you do want to acknowledge the bug report quickly, and then provide a timeline within which you will validate the bug, and if you do find it is a false positive, that communication should also instill confidence in the security researcher that that is indeed the case.
A suggested approach
The best bet might be to start out with an official program announced on your website and publicised over social media, hacker communities and security conferences. You may want to go easy on the publicity initially, till your internal processes and communication channels are fully worked out. Else, you might get flooded with hundreds of bug reports and a really irritated development team that simply decides to ignore the entire initiative. Or you could decide to run it for a brief period such as the ‘Hack the Pentagon’ program, and based on the results and internal traction you could launch it more formally. Or you could launch it only for specific products, such as a recently launched mobile wallet.
Another way to go is to do this privately. Currently – as per a Bugcrowd report for 2015 – nearly 63% of organizations that run a bug bounty program do so privately. Set everything up just as you would for a public launch, but send the invites out only to selected security researchers and maybe your own vendors.
Most vendors will usually put their best resources where the projects are most lucrative. This means that if you’ve negotiated heavily on a pen-test engagement, you’re probably not getting the cream of the crop from the vendor’s team. But inviting these teams to be part of your private bug bounty program changes all of that. You get the best guys to break your apps and they get incentivized directly. Plus, running it in private allows you to gather valuable feedback from the community on how well it is structured and if the payouts are sufficient to motivate them to keep looking for bugs.
An internal team – possibly beginning with one person – could be tasked with validating the submissions and communicating with the researchers to find out more details of the vulnerability. Once confirmed, the security analyst would then communicate with the product teams to get it fixed and confirm it back to the researcher. Once the researcher is also able to confirm that it is fixed, the information could be published on the organization’s wall of fame.
Once you begin to see the value of this approach, it will become easier to justify to finance and legal the need to begin a payout program around the bugs being reported. While you need not go to the extent of a Google ($4 million paid out since 2010-2014) or Facebook (paid out more than $1 million in 2014 including $22,000 in 2016 to an Indian researcher Anand Prakash), you could work out an annual budget approximately equal to what you pay for an annual penetration test or red team assessment at your firm. Averaging this out across the total number of bugs determined by your own security assessment exercises over the past one year on Internet-accessible applications could give you the average amount you could pay per bug reported through the program.
Of course, the above calculation needs to be kept as flexible as possible since the number of actual bugs reported through your program could exceed what you found internally by far. As Collin Greene of Facebook’s security team notes that within the first quarter of starting their program they got 71 bugs, far more than those that he had found out in his own testing efforts.
Going with a bug bounty platform
As mentioned earlier, there are a number of bug bounty platforms that help facilitate the entire process for you – of course for a fee. Signing up with a platform eases your headache of navigating the tricky aspects of publicizing the platform, receiving bug reports, communicating with researchers in case the bug reports are not clear, triaging, etc. Also, in those cases where the bugs reported are false positives, the bug bounty platform’s credibility would help convince the researcher that it really isn’t a bug that was reported.
Importantly, the bug bounty platforms serve as a magnet for security researchers across the globe and also provide you a hacker reputation rating that further helps improve the quality of the report submissions.
Conclusion
Hackers today have many avenues to earn bug bounties. They could earn from not only the companies that are on the bug bounty platforms, but could also spend time researching software that are part of the Internet Bug Bounty program (those that are public and power huge parts of the Internet) or they could spend an entire year finding a single bug that would make the folks at Zerodium happy enough to pay $500,000!
Getting these security ninjas to look at your apps and report them through your bug bounty program requires open and clear communication, time, patience, and willingness to work with a group of people that may range from borderline extortionists to your best security collaborators!
Post script
Another interesting statistic that emerges from the Bugcrowd report is that India contributes the largest number of researchers to Bugcrowd – 40% of the total of 500 researchers who participate on that platform are from India. This contrasts heavily with the near complete absence of any Indian companies running such programs. With the notable exception of Ola Cabs and Paytm there aren’t many Indian companies running a Bug Bounty program. So the time is ripe for more Asian companies to tap into the local talent!
