Earlier this month, a critical FaceTime security vulnerability was found by an ordinary 14-year-old and reported by his mother to Apple. The discovery of this bug, and the struggle to report it, serves as an eye-opener for many organisations. Responsible disclosure can be challenging, even for those operating an invite-only bug bounty programme, such as Apple. No company wants to be the last to hear about a critical vulnerability an end-user found in their product or website. So how can organisations better work with hackers to find their critical vulnerabilities fast? There are several best practices any company can follow to increase the chances for disclosure success.
It’s important to first understand the differences between responsible disclosure and bug bounty programmes. A vulnerability disclosure policy (VDP), commonly referred to as the “see something, say something” of the internet, is an organisation’s formalised method for receiving vulnerability submissions from the outside world without offering rewards. A disclosure policy is often associated with the ‘‘security@” email address. A VDP is a great first step to dealing with incoming bug reports and building a team and a process for handling those reports. Ideally, you want a disclosure policy that is easy to understand – not just by hackers, programmers or security researchers, but also by ordinary people who may stumble upon a vulnerability while using your product or service. A disclosure policy that is too technical and involves too many hoops to jump through can hinder the effectiveness of a disclosure programme, like we saw with FaceTime.
A more proactive approach to vulnerability disclosure is the use of a bug bounty programme (BBP). BBPs leverage hackers who can specialise in specific attack surfaces and vulnerability types. These programmes can be time-bound, private invite-only or public. The benefits of a BBP is that they give an organisation access to a diverse community of hackers, which can significantly increase the number of critical vulnerabilities that can be found at the fraction of cost of traditional pen testing. Furthermore, a BBP creates performance-based incentives for hackers to focus on what matters most to an organisation. Many companies choose a BBP because of the pay-for-results model as well as the quality and quantity of valid vulnerabilities that wouldn’t otherwise be identified through traditional security scans.
When considering a VDP or a BBP, it is essential to evaluate the vulnerability management (VM) process that is already in place. You’re going to have streams of vulnerabilities coming in from different sources, such as automated scanners, issues uncovered by security engineers, developers, or external consultants, or even someone publicly posting a zero-day. With a VDP or a BBP, you’re essentially adding a new stream of bugs into your existing VM processes. It is important to first prioritise these issues, typically based on severity. Once you’ve prioritised them, you have to hunt down owners to ensure the bugs get fixed in a timely manner. It’s extremely important to ensure you have a solid process in place for communicating vulnerability information to the right owner, including the severity of the issue and expected remediation timelines. Give your developers a heads-up that bugs are coming as soon as you can. Explain that any bug identified through your programme is live in production, and fortunately a friendly hacker has taken the initiative to report it to you. This means a malicious attacker could also find the same bug, which creates real-world motivation for more timely remediation.
Before launching a VDP or a BBP, it is important to identify a bug bounty leader (BBL) as well as members of the bug bounty team (BBT) early on. Running a BBP or VDP requires a large variety of tasks, such as triaging bug reports, communicating with hackers, defining and dishing out bounty amounts, and vulnerability management, among others. The best way to share the load is to set up a weekly on-duty rotation. You’ll want to clear out the calendars of your team for the first week when you launch. There’s often a large spike in activity at the launch of a programme, and this is also the time when you’ll quickly identify and course-correct for any hiccups in your programme.
Choose a platform provider. Many companies choose to deploy VDPs or BBPs with the help of a bug bounty platform provider, such as HackerOne. It’s possible to run a programme in-house, but things such as tracking the status of reports, processing payments and attracting and maintaining relationships with top hacking talent are a lot easier with a bug bounty platform. The benefits of working directly with a provider are that they can do all the work for you, including sifting through those incoming reports and finding the truly valuable ones that require remediation.
If you are offering hackers incentives, determine how much to pay per bounty. The simplest way to figure out payment amounts for bug bounties is to set up a bounty table. A bounty table illustrates how much you are willing to pay for various bugs, helps set expectations for hackers, and gives you and your team a guideline to ensure fair and consistent reward amounts. Typically, you want to pay out based on the severity of the issue identified. For example, HackerOne provides CVSS (common vulnerability scoring system) scoring in-platform to assist with this. Both hackers and teams can use CVSS to calculate a severity, or simple pick one from low, medium, high or critical categories. It is recommended to start with the median values. And it’s best to ramp up your bounties as bug scarcity increases, as opposed to going too big initially. Once you have a feel for your flow of bugs, you can increase your bounty ranges. Higher bounties result in more attention, especially from higher-ranked hackers with polished skillsets.
If you chose to offer monetary rewards, you’ll need to determine how to pay your hackers. Without using a platform provider, your finance and operations team will have to manage the entire process including compliance, taxation, covering processing fees, dealing with currency exchange rates, and other logistics. The benefit of using a bug bounty platform is that it handles all of this for you, making the payment process quite seamless for everyone that is involved.
It may seem counterintuitive, but running a VDP or a BBP is akin to providing a service to hackers who participate in your programme. The most successful bug bounty programmes have well-defined service level agreements (SLAs) that they share with hackers on their rules/policy page. The three big SLAs to consider are:
- Time to triage/response on a new report
- Time to bounty (after validation)
- Time to remediation
Finally, transparency between hackers and security teams is vital to a successful disclosure programme. The “front door” for hackers to any bug bounty programme is the security page, which contains your disclosure policy, rules of engagement, scope, and other important information. The purpose is to steer hackers towards the scope and vulnerabilities you care most about as well as setting clear the expectations around bounty pricing and timelines. You should ensure your rules page includes the following elements:
- A well-defined scope
- Bounty structure
- Qualifying versus non-qualifying vulnerabilities
- Service level agreements
- Eligibility/participation requirements
For an in-depth look at bug bounty program best practices, check out the Bug Bounty Field Manual ebook, located here.
By Jon Bottarini, Hacker and Lead Technical Program Manager for HackerOne