Laurie Mercer, security engineer at HackerOne, reveals what it takes to launch a successful bug bounty program.
Nobody wants to pay a juicy GDPR fine. Yet the more information that is available through internet-connected services, the greater the risk of a data breach. The quickest and most efficient way to find vulnerabilities in internet-connected systems is to run a bug bounty program.
The question I hear the most when talking to companies wanting a bug bounty program is “how do I get started?”
Here are four questions to ask yourself to understand how to get started:
Also of interest: Could veterans be the answer to the cyber skills shortage problem?
In-house or outsourced?
Before platforms like HackerOne existed, all bug bounty programs were in-house. One of the first was for the popular web browser, Netscape. Back then, hackers could only submit a vulnerability report over email to the security team, encrypted with a PGP key. This email would be forwarded to the team to fix the issue. Any payment to a hacker would be made as a direct bank transfer through the finance team.
For a small volume of reports, this can work. However, as the number of reports increases, there are several challenges:
- Vulnerabilities are unstructured and management becomes difficult
- Beyond an email address, it is difficult to know who the hacker is
- Communications do not integrate into SDLC tools and are not auditable
- The triage of bugs requires a dedicated 24-hour team
- Paying people all over the world is not simple
- What if the vulnerability is not in your code?
Also of interest: Hyatt launches bug bounty programme to uncover security vulnerabilities
Who needs to know about it?
A bug bounty program is quite different from normal security solutions and relies on cross-functional teams to be successful. Specifically, bug bounty programs will require input from:
- Security teams, including Incident Response, Application Security and the Redteam.
- Legal teams team: approving the policy, wording Safe Harbour statements in line with local and international law
- Comms and Marketing: bug bounty programs involve dealing with the public and public programs are often accompanied by press releases and blogs
- Engineering: Engineering need to actually fix the bugs found, and have limited knowledge and capacity
- Suppliers & Vendors: Bugs often affect 3rd party software and multi-party coordination is necessary to fix and patch successfully
This is why a program management team is often necessary to run a successful program.
Also of interest: Red Team: Not all superheroes wear capes
What resources are required?
Resources required by a bug bounty program include staff and bounties. To manage both, it is a good idea to choose a Bug Bounty Leader (BBL), the ultimate owner and champion for your bug bounty initiative.
Once the BBL is established, they need to form a bug bounty team (BBT) to support the ongoing program. The BBT is typically composed of members of the security team, and stakeholders from finance, legal, communications, engineering and your vendors’ teams.
Also of interest: Can we protect our National Critical Infrastructure from a major cyber-attack?
How much should I pay for a bug?
Set your reward structure too low and you will not attract researchers who can find bugs in your system, set your reward structure too high, and you may end up with an uncontrollable budget. Creating a reward structure is not an easy job.
Bounties should take into account severity, impact and estimated time spent for discovery. Additionally, to calculate the appropriate rewards for bounties, organisations should look at what others are offering to make sure their bounties are competitive.
The bug bounty should also be clearly defined and structured so hackers can understand the rewards they can receive. A top reason for a hacker rejecting an invitation to a private program is lack of clarity over the reward structure.
It is also important to ensure hackers are paid on time. Fast payments improve your standing with both groups.