Bug bounty – what’s in it for business?
Hack the Pentagon, a pilot bug bounty programme launched by the U.S. Department of Defence (DoD) in partnership with HackerOne, was the first-ever federal government-initiated cyber security bug bounty programme, writes Tej Aulakh, a managing consultant at Spirent.
Hackers were invited to register before 22 April to be submitted to a background check. Those accepted had until 12 May to identify and resolve security vulnerabilities in the Pentagon’s public facing websites, with the prospect of possible bounty payments from the $150,000 programme funding pool.
Bug Bounty schemes are a tempting solution to the endless stream of malware and cyber-attacks flooding our networks. They are very much in the spirit of current crowd source thinking. The saying “it takes a thief to catch a thief” suggests that it might also “take a crowd to catch a crowd” – in this case the faceless crowd of cyber criminals lurking out there. Another argument: why spend money on highly trained specialists when there are so many bright young minds with time on their hands and eager to put your system to the test in hope of a modest reward?
Now, with apparent endorsement from the highest levels of national security, you might agree that Bug Bounty is the way to go. But does it really spell the end of specialist developer security training, source code reviews, QA testing, third-party penetration testing and other professional security services?
Hack the Pentagon
Crowd sourcing security was a bold step for government to take, so it was launched as a pilot project in partnership with an established Bug Bounty-as-a-service firm, HackerOne, based in of Silicon Valley. The project was also restricted to target several public-facing DoD websites – and no critical, mission-facing computer systems were included in the challenge.
A registration site was established and all participants had to meet specific criteria: for example, they had to be US citizens, but not on the U.S. Department of Treasury’s list of people and organisations engaged in terrorism, drug trafficking and other crimes. Successful participants also underwent a basic criminal background screening to safeguard US taxpayer dollars.
By providing a legal avenue for the responsible disclosure of security vulnerabilities, bug bounties are meant to encourage the hacker community to contribute to the security of the internet. As Secretary Carter, who launched the department’s Defence Digital Service last year, put it: “This initiative will put the department’s cyber security to the test in an innovative but responsible way. I encourage hackers who want to bolster our digital defences to join the competition and take their best shot.”
For a start, Hack the Pentagon had the advantage of the US government’s detailed records to help screen applicants for suitability. Although large tech companies have been running their own bug bounty programs, most small and mid-sized organisations do not have the necessary security expertise, time and resources to screen applicants in such depth, nor to properly manage the resulting crowd response.
Even when candidates have been thoroughly vetted and a bug bounty program is running smoothly, there is the signal to noise issue: how much time might a company waste following up a flood of minor issues, erroneous bug reports, or real ones that its own in-house team would discover at no extra cost? Even the experts from HackerOne admit that: “The signal rate of valid, unique vulnerability reports on our platform for public bug bounty programs is 23% – more than triple of any other major independent bounty programme (Google’s is 7% signal). For invitation-only programmes on our platform, where only top-tier hackers are invited to participate, the signal rate jumps to 44%.”
The role for bug bounty
HackerOne’s chief policy officer, Katie Moussouris recognises the challenges in setting up a secure bug bounty programme. She says it can be especially difficult for large companies with legacy codebases, multiple product lines, and complex ecosystems.
Companies must also have its own security expertise, or access to partners offering recognized security skills such as static analysis, threat modelling, fuzzing, and penetration testing: “In short, the organisation needs to adopt a secure development lifecycle or application security programme. Developing a vulnerability response programme comes later.”
When security comes first
Hack the Pentagon was a bold move by government not only to heighten security but also raise awareness of its importance for the nation. It was also potentially a smart recruiting move, to sound out some of the brightest IT minds around – though not much has been announced about the actual results of the exercise, for obvious reasons.
It also looks like a public endorsement of bug bounty as a valid solution – except that we should not forget that the government is much better placed than any enterprise to thoroughly screen its candidates. It is also certain that the DoD already has its own rock solid internal security processes in place, and that bug bounty is an addition rather than a replacement for these.
Nor is bug bounty a viable option for testing applications processing private and sensitive information. It takes one level of trust to expose vulnerability, but a far higher level to give the researcher access to the data being protected.
In any case it would be very rash to trust all your security issues to a bug bounty programme without first getting the basics in place. These should include a security audit using the OWASP Top 10 and SANS Top 25 attacks to assess vulnerability, together with professional penetration testing. When security is a major issue, Secure Software Development Life Cycle (SSDLC) processes should be well established to reduce the cost of uncovering security bugs after the code goes public. Even the companies championing bug bounty services have their own well-established software assurance processes for security testing.
While bug bounty programmes could feasibly improve web security for some organisations, the essentials of security testing and monitoring cannot be replaced. These will include developer training, source code reviews, QA testing and internal and third-party penetration testing as essential safeguards.