At HackerOne’s 2021 Security@ conference, we spoke with Douglas Day, an experienced ethical hacker and senior product security engineer who has managed Elastic’s bug bounty program for the last two years.

During the chat, Douglas explained how Elastic has built and maintained an active bug bounty program —without offering the highest bounties around.

The Pillars of a Strong Bug Bounty Program

In his career as a hacker, Douglas uses three criteria to establish whether a bug bounty program is worth his attention:

  1. Bounties. Do the bounties offered deliver a good return on the time invested in the program?
  2. Scope. Does the program scope include interesting products or techniques, along with all of the information needed to effectively start hacking?
  3. Response time. How quickly does the program pay hackers for verified vulnerabilities, and how long does it take the company to fix issues?

Let’s take a closer look at each of these criteria.

How To Be Competitive (Without a Multi-Million Dollar Budget)

Many organizations face a challenge when starting a bug bounty program because they can’t compete with longer-running programs on bounty dollar amounts. Some programs offer bounties as high as $30,000 for critical vulnerabilities, which is impossible for many organizations.

However, large individual payments aren’t the only way to make money for a hacker. Douglas explains:

“It comes down to getting a good return on time invested. As a hacker, I’d rather spend two hours finding twenty $500 bugs than spend 20 hours finding one $10,000 bug.”

Finding a critical vulnerability in a long-established program may be more difficult than finding one in a new program. So while the bounty payment will be higher, the reason is likely because the organization running the program has a stronger security posture.

Once you understand this, building a competitive program comes down to balancing bounty payments against the difficulty of finding vulnerabilities. To get Elastic’s program off the ground, Douglas’ team decided to open up the program scope to include less frequently-tested assets, allowing hackers to gain a high ROI for their time without offering particularly high bounties.

Elastic went further by turning its bug bounty program into a game, including a set of challenges that hackers can compete in to earn bonus rewards. For example, by reporting seven consecutive, valid bugs, a hacker can win a bonus of $700. A full table of challenges is published on the organization’s bug bounty program page.

Douglas also emphasizes the importance of understanding what frustrates hackers about many bug bounty programs. For example, if a bug is downgraded in severity pushing it into a lower severity category (e.g., medium instead of high), that can significantly impact the bounty payment. By setting bounty ranges for each severity instead of fixed figures, Elastic minimizes this problem, ensuring hackers receive fair payment for their work.

Scoping a Bug Bounty Program

Organizations should scope bug bounty programs to fit their needs, but it’s also worth considering what makes a program attractive to hackers. A common tactic to encourage hackers to focus on specific products or techniques is to provide additional financial incentives targeted directly at those activities.

Beyond this, always ensure your scope includes everything a hacker needs to get started. If hackers have to communicate with an internal team to get credentials before starting, the program may be less attractive. A self-sign-up option can alleviate this, allowing hackers to begin immediately at any time. Remember, the hacker community is global, and may want to work on your program outside your office hours or on public holidays.

Make sure your documentation includes everything hackers need to determine whether something is a bug or legitimate functionality. Understanding how your products are supposed to work is fundamental to bug hunting.  Don’t force hackers to waste time on basic functionality queries.

Response Times: It’s Not Just About Payment

Everyone likes to get paid on time, so it should be no surprise that hackers prefer to engage with programs with a speedy time-to-bounty metric. However, hackers care about other things too. There are four metrics that hackers pay attention to when deciding which programs to engage with:

  1. Time-to-first response
  2. Time-to-triage
  3. Time-to-bounty
  4. Time-to-remediation

While it may be obvious why hackers are concerned about the first three metrics, organizations often overlook the importance of time-to-remediation (TTR). TTR is important to hackers for two reasons:

  1. If a program has a slow remediation time, that typically  means there are many outstanding bugs. This increases the likelihood that a hacker will report a known bug for which they won’t be paid. This is understandably a concern for hackers, as they will have wasted time finding and documenting these bugs.
  2. Hacking is not just about earning a financial reward. Hackers seek to make a difference by improving the security profile of organizations. If organizations don’t fix the bugs they report, a hacker’s contribution becomes purely transactional, which is far less fulfilling. If organizations don’t fix the bugs they report, a hacker’s contribution becomes purely transactional, which is far less fulfilling.

Again, understanding hackers’ motivations and frustrations are crucial when building and optimizing a bug bounty program.

Keeping Hackers On Board

Attracting hackers to your organization’s bug bounty program is step one. But you also need to keep them on board. Achieving this is all about mastering other aspects of bug bounty. From his hacking career and experience driving Elastic’s bug bounty program, Douglas cites three crucial factors that keep hackers engaged:

  1. Relationships. Money is important, but human relationships are also critical. Bug bounty program managers should build strong, personal relationships with regular contributors, recognize their efforts, and take time to thank them for their work.
  2. Transparency. A clear program scope explains what hackers can and can’t do. Program managers should keep hackers involved while investigating bugs, strive to respond quickly to new reports and questions, and provide feedback even when a reported issue isn’t in line with the program scope. When hackers feel valued, this will impact whether they continue working on a program.
  3. Feedback. Top bug bounty programs invariably have a strong feedback loop between the organization and the hacker community. Hackers have useful input and ideas, and keeping communication lines open ensures they feel appreciated and engaged with the program.

To illustrate the importance of these factors, Douglas talked about a private program he had a positive experience working on:

“The bounties were competitive but not obscenely high, and the scope was only one application at a time. But we developed a great relationship with the program manager. The manager was singing our praises as we reported vulnerabilities. He knew our skill sets, so he would cater the scope to fit them. The response time was phenomenal, and we were often paid on the same day for critical reports. It’s still one of my favorite programs, and I still hack there.”

Learn More About Working With Hackers

Register here to watch this training session on how to attract and retain top hackers for your bug bounty program. Also, explore our other on-demand training and presentation sessions, presentations, and roundtable discussions from Security@ 2021, our 5th annual global cybersecurity conference.

Posted by Charlie