[BreachExchange] Is Your Company Ready For A Bug Bounty Program?

[Destry Winant]

https://www.forbes.com/sites/christieterrill/2018/09/05/is-your-company-ready-for-a-bug-bounty-program/#5fcd83465204

The idea of crowdsourcing information security help from hackers might
seem like an odd accepted practice, but it’s clear that bug bounty
programs are here to stay. Bug bounties have become an important part
of many security programs.  Companies that are dedicated to protecting
trade secrets and personal information collected from customers and
employees have successfully used bug bounty programs to enhance their
security efforts.

To define what a bug bounty program is, at their core, bounty programs
should act as an incentive for legitimate security researchers to
report security vulnerabilities in software that could be targeted by
external attackers. These efforts provide researchers an avenue to
hunt for bugs without fear of legal retribution, and at the end of the
day, also collect a paycheck.

The temptation for some companies who see other enterprises publicly
touting the success of their programs is to dive headfirst into their
own. But this isn’t an easy path. A certain level of maturity is
required for a successful bug bounty program, not to mention a fair
amount of preparation, legwork, and restraint.

Many organizations see a bug bounty program—whether it’s a
self-managed program or one that’s run through a commercial platform
provider—as a way to cost effectively crowdsource their vulnerability
identification process.  It can also be a useful tool in your
vulnerability management toolbox. But there are pitfalls to jumping
into a bug bounty program too quickly, and most organizations simply
are not mature enough or staffed well enough to withstand the deluge
of reported vulnerabilities.

Many public bounty programs are also launched with notable public
relations and marketing fanfare. If you’re a big enough company, the
media is going to write and podcast about your program and the
industry leadership you’re demonstrating in reaching out to a trusted
community to find bugs in your web apps. You better be ready.

Here are five milestones you need to hit before you know you ready for
a bug bounty program:

1) Know How this Will End What do you want to accomplish? Companies
run private bug bounties and public programs for many reasons, ranging
from the obvious of enhancing a vulnerability management program or
secure development lifecycle, to garnering some good publicity for
your security team. Setting these objectives at the outset will shape
your program, from what’s in scope for outside researchers to test, to
the rewards you’ll eventually offer. There has to be internal
alignment on program goals, or you’re doomed from the start.

2) Fair Game Speaking of scope, this is crucial and it’s probably wise
to start small. Many programs begin public bounty programs with a
narrow scope, limiting what’s fair game for bounty participants to,
for example, public-facing web applications that do not require
authentication. Spell out targets clearly for bug hunters otherwise
misunderstandings are sure to discourage participants, hurt the
reputation of your program, and leave you well shy of the goals you
want to achieve through the program.

3) Receive in Order to Remediate So many bug bounty programs stumble
out of the gate because they don’t have a proper mechanism in place to
receive and triage bug reports. It seems like a simple and obvious
step, but it’s among the most important. This is your program’s
doorway to the public and it has to be clearly visible and spelled out
on your website for bug hunters. It could be as simple as a plainly
visible security at company email address, or a well-thought-out
submission form. Show you are security savvy too; provide participants
with public encryption keys to simplify the submission process via
email.

4) Talk to Me Money motivates bug-hunters, it’s true. But most are
genuinely motivated by doing the right thing and making the Internet
and ecommerce secure. When a submission happens, have a mechanism in
place to communicate expectations with a bounty participant. Have the
resources in place to evaluate bug reports, confirm bugs as
legitimate, and respond to the researcher that the bug is in scope and
unique, qualifies for a reward, and that they’ll be paid within
x-number of days/weeks/months. Many relationships with bug hunters
fall down at this stage, and frustration quickly grows to the point
where a researcher could decide to disclose a vulnerability, or
publicly express their frustration with the program to the point it
damages its credibility.

5) SDL is Hungry; Feed It: You must be ready to feed bug reports and
remediation options to your secure development lifecycle, otherwise,
what’s the point of finding bugs in the first place if you’re not
going to fix them? Internal engineering and quality control teams must
be onboard and trained for the volume of bug reports you’re going to
receive, especially at the outset. Be ready for the onslaught and
understand the importance of assessing only unique bugs and quickly
reporting duplicates to submitters. The stress on engineering, QA, and
developers will be significant as a bounty programs rolls out and
reports roll in. Don’t proceed without a framework in place to receive
and remediate bugs. Otherwise, you run the risk of not only failing to
meet your program’s goals, but also, in a worst-case scenario, of
paying out for bugs that don’t really matter.

Bug bounties are part and parcel to a vulnerability management program
and should never comprise the entire process. They are a complement to
ongoing penetration testing engagements and should never preclude an
organization from continuing and managing their own vulnerability
assessments. The clear goal should be a proactive approach to security
and remediation, with a reasonable goal of wiping out classes of bugs
rather than fixing one-offs for all eternity (wipe out those
cross-site scripting bugs once and for all). Invest in your SDL and
triage processes and be sure about what you want to accomplish, and it
helps to start small and limit your scope. You want to create
incentives for researchers to find bugs, and a great experience keeps
them coming back and keeps your company safe.