Begin your bug bounty program with shared inboxes

“What I did in my youth is hundreds of times easier today. Technology breeds crime.” - Frank Abagnale

At 2019 Gartner summit, I had a chance to sit in the front row for the keynote speech by Frank Abagnale. Abagnale is famous for the cons documented in the Hollywood blockbuster, Catch Me If You Can, starring Leonardo de Caprio. Abagnale later went on to work with the FBI uncovering check forgers.

In the same way Frank Abagnale helped the FBI, a bug bounty program can help your organization.

Bug bounty programs unite ethical hackers and researchers to help organizations stay one step ahead of the bad guys (or threat actors), and detect vulnerabilities in their environment. 

You could be a growing startup with a paying B2B customer base. You have a small team of developers and product managers, who are also responsible for the security of your application. With an increasing number of bugs being reported on social media and public domains, you want to implement a bug bounty program for your mobile app, that will be used by your clients’ employees.  

Or

You could be an enterprise with a large B2B footprint offering multiple products across various domains. You already have a private bug bounty program for all your critical offerings through crowdsourced platforms, like Bugcrowd or Hackerone. However, your security department would like to set up an in-house program, with limited scope and a small internal team, to accept and triage bug reports from users across all channels.

Running an in-house bug bounty program can be quite overwhelming, and may lead to a flood of emails from hackers and researchers reporting bugs. With no reputation system in place, your security team will have to screen each report for non-issues, duplicates, and out-of-scope information.

From our own bug bounty program at Zoho Mail, fewer than 5% of reported bugs are actual defects that lead to compensation, and only about 2% are informative. 25% of reports are not issues and over 10% are duplicates.

A number of disparate teams become involved at different stages of the bug lifecycle, from reporting to disbursement of bounty. Smooth functioning of the bug bounty program requires screening and skillfully organizing submissions, collaborating for triage, timely assignment of ownership, and automation of repetitive processes.

Every team ends up running a bug bounty on one of the platforms at some point along their growth journey. But it always begins with good old mail.  

We've reimagined the bug bounty process with shared inbox—an inexpensive yet intutive tool with applications in a number of team collaboration use cases. A shared inbox (or team inbox) provides a unified collaborative space so multiple users can access, read, and send emails. This enhances team productivity and ensures transparency, visibility and credibility among members. Here is a useful article on shared inboxes and how they help organize workspaces. 

In this article, we’ll discuss ways to build and optimize your bug bounty program using a shared inbox to consistently improve productivity and maintain healthy relationships with the hacker and research communities.

1) Identify the stakeholders: A shared inbox is a suitable application for this use case because bug bounty programs involve considerable cross-functional collaboration over submitted bug reports.

Triage team: Once selected, the members of your triage team can be added to a mail group in your shared inbox. Ideally, the triage team is comprised of the product manager, lead tester, technical lead, and development lead.

Depending on your internal processes and anticipated inflow, you may choose to create a siloed group inbox or folder just for triaging. However, to begin the program with a small team and limited scope, you can form a single group with all stakeholders.

At various stages of the bug life cycle, you can members from additional teams, such as legal, compliance, PR, and corporate communications, to your bugbounty@ group, along with your data protection officer (DPO).

2) Vulnerability management and a "level zero" approach: It's important to define the process your teams will follow once a bug is confirmed. A bug bounty program demands the time and effort of existing resources to respond to researchers and fix bugs without disrupting business continuity.   

Level zero: As with all use cases that involve external communications, your inbox is "level zero," for your bug bounty program. Manage all the screening, organizing of incoming emails, and replies within your inbox, without needing to forward messages or copy collaborators.

Instead of subjecting technical teams to a flood of submissions, consider training a junior level resource as the "level zero agent" for your program.

Establish necessary automation rules and triggers, including blacklisting or whitelisting emails to filter out spam and out-of-scope messages.

3) Documentation: There is a considerable amount of documentation that goes into the launch of a bug bounty program. All involved parties should have access to necessary information, and should be able to produce it to hackers whenever necessary. Start with a bounty brief that describes the rules of engagement for hackers, the code of conduct, terms of disclosure, and the research terms and conditions. The following are essential elements for your documentation:

Scope: Define the scope of the program. Where should researchers focus their testing? What’s in scope? What’s out of scope?

Access: Provide researchers with access to your scope and help docs, source code, and libraries.

Standards: How will you rate submissions? Define and share the standards you would like the hackers to refer to, such as common weakness enumeration (CWE) by MITRE’s,  OWASP top ten, or Bugcrowd’s vulnerability rating taxonomy.

Reward range: Disclose how much you will pay for vulnerabilities upfront.

Safe harbor: Assure researchers that they’ll be safe from legal action and exempt from your end user license agreement(EULA) when operating within the rules of your bounty brief.

4) Announcement: Once you're prepared to launch your bug bounty program, send an announcement across channels to reach your target audience of ethical hackers and researchers. The announcement should carry the bounty brief and provide an email address (bugbounty@) where bug reports can be sent.

You should also advise your employees in public-facing roles on how to handle security reports and escalate potential security issues.

Communication with the hackers is the most important part of the bug bounty program—even if it is only a response to duplicate, out-of-scope, or no-defect submissions. That said, communication among teams through the bug life cycle is also crucial for the success of the program. Shared inbox facilitates seamless collaborative communication, making it one of the most suitable and cost effective tools to begin your bug bounty program.

Remember, to maintain a healthy relationship with hackers, you should reward them well and pay for well-written reports, including dupes.

There is no such thing as a foolproof system. That idea fails to take into account the creativity of fools. -  Frank Abagnale