CHAPTER 3
Thus far we’ve gone through a lot of the
blocking and tackling basics for the planning part
of your bug bounty program. Chapters 1 and 2
describe many of the planning details for your
bug bounty program.
You’ve determined you’re ready, primed your vulnerability management
processes, defined bug bounty roles and responsibilities, gone through
the details of your bounty process, set up a budget, created your policy,
and now – now you’re ready to sprint ahead to bug bounty glory!
Well, not quite. Have you gotten management approval yet for
the budget? Did you talk to all pertinent internal team members
and discuss the bug bounty process with them? As you can
see, and are now becoming more aware, championing a bug
bounty initiative requires a lot of people to be on-board!
It all starts with you, though. Your passion and commitment
to launching a program can (and will be!) infectious.
Think of it like you’re Luke Skywalker and your engineering
and development teams are Han, Chewbacca, C3PO,
R2D2, and Leia – you can’t win the battle yourself, but
without you, the whole galaxy will fall apart.
It’s your job to get the supporting cast on board. Part
of how you do that is to make sure everyone is aware of
how much value will be derived from these efforts.
Beyond the core cast members, you have PR, legal, and executive
leadership. Taking our Star Wars analogy further, let’s say they’re Lando
Calrissian, Obi-wan Kenobe, and Yoda (Lando is obviously the PR guy).
Involving everyone, gathering feedback, and showing them
the potential of this initiative will go a long way towards
launching and running a successful program, as well as result
in greater feedback loops and overarching improvements to
your security posture (more on this in chapter 4 and 5).
So this sounds great and all, but how do you actually go about doing it?
Your approach will vary depending on the audience. Here’s some high
level advice on factors to consider when approaching common teams
at most organizations.
3.1 Security Team
Depending on the size of your security team, maybe everyone’s already
on board! If not, you’ll want to consider this the center of your “onion,”
with additional layers around it: engineering, finance, legal, and PR. If
the core crew isn’t convinced, you’re going to have trouble taking off.
A bug bounty program is usually most relevant to whoever works on
product security. Since your program will identify every bug that fell
through the cracks of your product security team’s processes, there
can be an inkling of defensiveness. You may hear sentiments like “Why
do we need this? Our processes are fairly robust.”
Identifying these bugs and tracing them back to their root causes will
provide invaluable data for you and your team to discover where things
went wrong, and course correct as needed
The thing is — no matter how amazing your security processes
are — there will always be bugs that slip through the cracks.
Augmenting your security team with the help of friendly hackers
serves as an excellent safety net, as well as helps identify areas
where your security processes have failed
In addition to your product security, if you have a team that works on
detection and incident response, they’ll need to be in the loop as well.
Imagine it’s Friday night, you’re about to go home and relax, and all of a
sudden your intrusion detection system (IDS) starts blowing up in your
face. It looks like you’re being hit by automated scans from 10 different
countries. What’s going on!? It’s critical you inform your team ahead of
time that additional activity may be generated due to normal testing so
they aren’t caught by surprise.
3.2 Engineering
Whatever your engineering team is building (web apps? mobile apps?
IoT?), nobody likes unexpected work. When your bug bounty program
starts picking up steam, there’ll be plenty of security bugs to fix on a
regular basis. Some security teams take on the herculean task of fixing
security bugs across the entire organization, but the best way to scale
security is to empower all teams to fix the bugs themselves. This is
a huge topic that could warrant its own manual, but in short, you’ll want
to work with leaders across all departments of engineering to ensure
they are aware of your bug bounty initiative, and that they understand
the benefits their teams can derive from it. Your bug bounty program
will uncover flaws in engineers’ work. As mentioned previously, this can
cause some defensiveness, but leveraging this data to identify root
causes of systemic security issues in your environment is an immensely
powerful asset. In addition to improving your security team’s
capabilities to identify these flaws, you’ll be able to use this data to help
show engineers the real world impact of not embedding security into
development processes.
This sounds great in theory, but what happens when the bugs start
hitting the fan? Having spent a few years working on vulnerability
management at Google, I can tell you from experience that the more
of a heads up individuals and teams have around incoming work on
security, the more likely it is you’ll be successful in convincing them to
allocate adequate resources towards fixing bugs.
It’s impossible to predict exactly how many bugs will flow into each area,
or how long each of them will take, but it is within your power to ensure
your bug bounty machine is operating smoothly enough that you
can identify and notify owners of affected products of vulnerabilities
as quickly as possible. As mentioned previously in the vulnerability
management section, you’ll want to have a common language with
engineers to communicate the severity of various bugs, as well as
expected remediation timeline
Any bug found via your program is live in production; if a hacker was able
to find it and was nice enough to report it to you, a malicious actor is
probably out there sitting on the same bug. Even in organizations that
don’t normally have the best remediation timelines, this perspective
can help improve security culture throughout your organization.
3.3 Finance
Fortunately, HackerOne makes it easy to pay hackers, so the
process with your financial team should be straightforward!
When it comes to payments, you have two options:
- Add a credit card to your HackerOne account that gets charged for
any bounties paid out - Make a deposit in advance which bounties can be paid out from
Most organizations go for option #2. Whenever your team decides on
a bounty, you simply set the amount you’d like to pay on the report,
and it is withdrawn from your balance. Easy as pie! We recommend
stashing away three months’ worth of bounty budget at a time. With
HackerOne taking care of payments, you don’t have to worry about
compliance, taxation or figuring out how to pay a hacker in, say, Siberia
who doesn’t have a mailing address. HackerOne also collects the
appropriate tax forms, so you don’t have to worry about it. For more
information, check out this support article on the topic of payments.
3.4 Legal
Taking a look back in time, we can see the way that organizations
interact with hackers has changed immensely (and for the
better!). One great example is Samy Kamkar, and the XSS
worm he built that exponentially propagated through MySpace
overnight, affecting one million users, and forcing MySpace to
temporarily shutdown. Now – admittedly – he probably shouldn’t
have done something quite so destructive to a production
environment. That said, the repercussions were pretty big!
The secret service came to search his place, and he ended
up pleading guilty to a felony charge of computer hacking, and
was prohibited from using a computer for three years. Oh, and
he also had to do 720 hours of community service! There’s
a great video where Samy talks about this experience.
In any case – we’ve come a long way! These days, instead of being
threatened with legal repercussions, friendly hackers are actually
rewarded for responsibly disclosing vulnerabilities. We’ve already talked
about crafting your policy/rules page – setting rules of engagement
and communicating with hackers about what is (and isn’t!) okay. Having
clear guidelines like this in place greatly reduces the risk of a “Samy
situation,” where a hacker inadvertently impacts your production
environment. Lastly – when working with legal, you’ll want to be sure
they have a chance to review HackerOne’s terms and conditions.
3.5 PR/Comms
While most organizations start with a private, unannounced bug bounty
program, it’s still very important to keep your PR and communication
teams in the loop. Especially for PR teams that haven’t dealt much with
information security, there may be a hint of cautiousness when they
hear about your initiative. I’ve sometimes heard sentiments like…
• Isn’t having a bug bounty program the same as admitting we
can’t handle security ourselves? It makes us look weak!
• What if a hacker exposes our data?
The U.S. Department of Defense’s “Hack The Pentagon”
program is another great example. When communicating
with your PR team, you’ll want to convey:
• It’s impossible to catch everything yourself
• Bug bounty programs let friendly hackers work with
you to help identify issues before the bad guys do
• Big name companies and organizations (even the Federal
Government) have bug bounty programs – they are a best practice
• These days, not having a program actually
puts you behind the curve
Overall, you’ll want to ensure all internal stakeholders are aware of
your timeline to launch and are ready to rock. It can be helpful to set
up a high-level presentation advertising the benefits of a bug bounty
initiative at your organization; you can use this as a reference to
demonstrate value and become a bug bounty hero within your org.
Here are a few resources to check out, and perhaps share internally:
• Riot Games’ David Rook’s talk on Running a Bug Bounty Program
(~21 minutes)
David Rook provides some great advice based on his
experience running Riot Games’ bug bounty program.
• 5 reasons not to run a bug bounty program (~25 minutes)
This is good ammo for addressing common concerns
that come up around running a bug bounty program.
• Bug Bounty 5 years in
Great post by Collin Greene based on his experience
running bug bounty programs at Facebook and Uber