Fight Fire with Fire: How Bug Bounty Programs Improve Cybersecurity

Share this via:

The expression “fight fire with fire” seems counterintuitive when you first think about it. Small controllable fires, however, remove flammable material and deprive a larger fire of fuel. These small fires can stop the spread – as long as the small fire does not get out of control.

In essence, this is the motivation behind Bug Bounty Programs (BBPs). Increasingly complex information systems make it difficult for firms to trace and fix critical weaknesses in their security. Because of this, firms use BBPs to crowdsource the discovery and fixing of vulnerabilities. External security researchers attempt to expose and report “bugs” or vulnerabilities before they get exploited by malicious hackers. Firms pay security researchers large sums of money – Google paid over $6.5 million last year – for finding vulnerabilities. These payouts, though, are still much less than the cost of recovering from a large-scale security breach.

Security breaches can cause devastating financial losses and affect a firm’s reputation for years. In the United States, the average total cost of a data breach is over $8 million, with many companies paying much more in lawsuits during the aftermath. For example, a data breach of all 3 billion Yahoo! users resulted in a $117.5 million class-action lawsuit and lasting damage to the company’s reputation. Bug Bounty Programs allow companies to utilize skilled researchers to prevent devastating security breaches.

Like when fighting a fire with fire, maintaining control of Bug Bounty Programs is critical to their success. In the article “Bug Bounty Programs for Cybersecurity,” Suresh Malladi (University of Arkansas) and Hemang Subramanian (Florida International University) discuss practices, issues, and recommendations for firms using Bug Bounty Programs for cybersecurity. They provide BBP best practices in five categories to help firms prevent the increasing costs of security breaches: scope, timing, quality, communication, and motivation.

1. Scope: If It Ain’t Broke…Still Check It

“BBP operators often focus exclusively on new products due to resource constraints and the novelty factor that attracts researchers,” but this approach ignores the possibility of vulnerabilities in aging (or legacy) systems. Many attacks specifically target older systems for this reason. In 2017, “WannaCry” ransomware attacked several large organizations using outdated Microsoft Windows operating systems such as Windows XP. The hackers demanded a ransom in bitcoin or else they would delete all compromised files. Firms, then, should not ignore older products when organizing BBPs, as they are particularly susceptible to attacks.

Even if all internal products are secure, acquired products and third-party relationships can create security loopholes. The authors recommend that “when launching BBPs, firms should audit products, interrelationships, and potential areas where gaps can emerge among both their own and external products.” A team is only as strong as its weakest link, and firms must strengthen their weak links before hackers exploit them.

BBPs differ from traditional crowdsourcing efforts in that the problems and solutions are both unknown. Because of this, “vendors should use BBPs to look beyond discovering vulnerabilities.” Outside of discovering vulnerabilities, participants in the programs bring expertise in fixing vulnerabilities, developing new tools, and automating the discovery process. Therefore, firms should incentivize experts to assist in all steps of the process.

2. Timing: It’s a Marathon, Not a Sprint

The timing and continuation of external engagement is critical. “Firms would benefit by building foundations for long-term defensive strategies rather than episodic engagements,” the authors assert. For example, instead of waiting until they had a finished product, Microsoft used crowd engagement to test Internet Explorer from the first stages of development through beta testing. Crowd collaboration throughout the development cycle improves researcher motivation, inclusively internalizes external talent, enriches engagement, and develops specific solutions for priority issues.

Waiting to engage with external researchers until after the product launch may allow hackers to exploit vulnerabilities before the firm can detect them. Open-ended BBPs before the product’s release, though, could expose security flaws that cripple the launch. The authors suggest that firms should engage “prequalified researchers through invite-only programs before/during beta testing” to recognize vulnerabilities early in the process. As the development lifecycle progresses, BBPs should become more open ended.

3. Quality: Staying in Control

Just as college graduates apply to hundreds of jobs in hopes of hearing back from some of them, researchers submit as many vulnerabilities as they can – even if they are invalid – to give themselves a better chance of receiving compensation. In fact, between 50-70% of submissions are invalid or partial. To improve submission quality, the authors suggest refining reporting and governance guidelines.

Essentially, firms should incentivize good researchers to submit more and penalize bad researchers for excessive invalid submissions. Although limiting the rate of submission and encouraging self-regulation through penalties may prove effective, these steps may be detrimental because they constrain participation. Instead, the authors suggest implementing reporting policies that reward higher accuracy with higher compensation to increase valid submissions. Invite-only programs could also improve accuracy by ensuring researchers are skilled and trusted.

“BBPs [should] not replace internal testing but only complement internal practices.” Relying solely on external researchers to find vulnerabilities leaves a firm exposed to the risks associated with BBPs. Systems may be susceptible to live attacks during testing, vulnerability fixes are not always effective, and researchers may not report the vulnerabilities they discover.

To mitigate these risks, firms can create a separate test environment, increase the frequency of vulnerability fixes, and modify compensation mechanisms. Holding researchers accountable and staying in control of the program protects the development process.

4. Communication: BBPs Are Not Hands-Off Efforts

“BBPs without resource commitment will be detrimental,” the authors write. “Firms should dedicate technical and human resources to handle, analyze, and follow through on every valid submission in a timely manner.” Poor communication negatively impacts a firm’s reputation, so firms should be transparent when communicating with external researchers.

The authors suggest simplifying the reporting process and using platforms such as HackerOne to manage the submissions process. Researchers from over 100 countries participate in BBPs, so complicated conditions and legal jargon discourage participation. Supporting multilingual disclosure would also improve communication.

Firms should be as transparent as possible in communicating reward mechanisms and compensation. Firms do not need to release the reward review process, but clear communication around prior ranges of compensation and the factors that impact rewards improves trust.

5. Motivation: Hackers (Don’t) Just Want to Have Fun

Sure, exposing a critical vulnerability in a massive organization’s security sounds fun, but researchers seek more than the thrill of the experience. “Researchers scout for frequent rewards and for creating a reputation in the research community,” the authors write, “Increasing chances to earn both helps retain talent.” Generous rewards and public recognition of contributions helps foster engagement between the researchers and the firm.

Challenging and motivating the researchers with high-priority projects improves effectiveness. In addition, expressing a desire to improve the safety of products rather than just testing products also could improve motivation. Working with, rather than working for, a firm in finding and patching new vulnerabilities increases a researcher’s motivation.

The authors find that “financial compensation is the sole motivation for researchers,” which differs from traditional forms of crowdsourcing. Higher rewards improve researcher retention and show a firm’s commitment to BBPs, but rewards should be dynamic and scaled according to an individual’s participation. If initial rewards are too high, there is no incentive to help fix the vulnerabilities. Companies such as Mozilla offer higher rewards if researchers help fix the issues they discover – incentivizing engagement with the firm.

Is Prevention Better Than Cure?

Bug Bounty Programs create value for firms and researchers alike by using collaboration to prevent massive security breaches. By providing researchers with more than just a free t-shirt, companies and experts have helped each other succeed. The future of this kind of crowdsourcing looks bright.

Every company, no matter the size, should focus intensely on cybersecurity. Enlisting external security researchers to uncover vulnerabilities prevents catastrophic security breaches that can destroy a company. In fact, data breaches caused 25% of small businesses to file for bankruptcy and 10% of small businesses to go out of business. Business leaders should follow these best practices to make the most of their partnerships with security researchers and protect their business.

As more and more companies rely on open-source software developers, crowdsourcing could help build security into software and focus on the prevention rather than the cure. It might be time for companies to fund these efforts to push security further upstream.