RSA 2015: Bug bounties - accepted but concerns remain

RSA 2015: Bug bounties - accepted but concerns remain
RSA 2015: Bug bounties - accepted but concerns remain

At the RSA panel discussion, Bug bounties: Internet saviour, hype, or somewhere between, moderator Jake Kouns, CISO, Risk Based Security, asked if bug-bounties – where companies pay freelance researchers for discovering flaws - are the way ahead, given that many companies which previously said that they would never have a bounty, now do.

Casey Ellis, CEO of Bugcrowd responded: “They are effective - that's the main thing. There are not enough people on the good side and this connects (software developers) with more resources.”

He was backed up by fellow panellist and bug-bounty user Nate Jones, technical programme manager at Facebook who said: “It's a good way to pay for results, not for time – so it helps us, rather than paying for pen-testing. We won't get the same coverage from pen-testers (who will have to ration their limited time) – so that's really positive.”

Chris Evans, ‘Troublemaker'(researcher), Google, added:  “You launch one of these and you increase your results. Your own internal team won't be able to compete with thousands and thousands of people (participating in a bug bounty).”

Ellis however did voice a word of caution: “Yes, all companies should have one, but it's not one-size fits all.  Google and Facebook are able to respond to reported vulnerabilities.”

An informed speaker from the floor added: “If you are not ready, you shouldn't do a bug bounty. If you haven't done internal pen-testing you are not ready. Only when you are ready is a bug bounty appropriate and then you can choose to go direct, go to third party, or crowd source.”

Jones, who said that Facebook received 14,000 reports last year as a result of bounties, added: “They help us incentivise people to reach out to us in a way we would like, and they can impact how they report, what they report, allowing us to communicate internally and externally. We do need to discuss it with our internal teams.”

A major downside identified was the potential high volume of responses, with Evans pointing out that a lot of people think they are reporting really critical issues and mostly they are not, so it can be difficult to get through all the noise.

Ellis pointed out: “A lot of people participating have English as their second language so frameworks need to be as complete as possible to get the response you want. You need to be able to differentiate good behaviour from bad. If customers are using our infrastructure for single source IP, different hacks, using tagging etc, it's not a problem and while we can't solve it 100 percent, we can ensure it's manageable.”

Another speaker from the floor pointed out that not all bugs are equal in terms of exploitability, and asked the panel, “How do you decide how much to pay?”

Evans responded: “We tell researchers as much as we can, we have a tabular format showing how much we pay for what bug type, and the likely price range. Certain bugs are particularly exploitable, and the more likely they are to be used, the better the bonus.”

Page 1 of 2