As we alluded to in the assessment questionnaire, you likely already
have some vulnerability management (VM) processes in place (i.e.
ensuring vulnerabilities are identified and fixed in a timely manner).
In any VM process, you’re going to have streams of vulnerabilities
coming in from different sources, such as: automated scanners; issues
uncovered by security engineers, developers, or external consultants;
or even someone publicly posting a zero-day!
You’ll then need to prioritize these issues, typically based on severity.
Once you’ve prioritized them, you have to hunt down owners to ensure
the bugs get fixed in a timely manner. When starting a bug bounty
program, you’re essentially adding a new stream of bugs into your
existing VM processes.
It’s important to ensure you have a solid process in place for
communicating vulnerability information to the right owner, including
severity of the issue, and expected remediation timelines.
When you launch your bug bounty program on HackerOne, you have
the ability to assign a severity to each report, as well as integrate with
common bug tracking systems (e.g. JIRA, Assembla). This streamlines
bug reporting and triage efforts. If you’d like, you can even invite the
developer responsible for the fix directly to the report on HackerOne!
Some organizations shy away from bug bounty programs because
they feel they aren’t ready for a new stream of bugs. I often hear
sentiments such as
“Our security team is already swamped, how can we find time to run a bounty program?”
“We have a hard enough time getting developers to fix security bugs in a timely manner
today, and you want me to pile more security bugs on top of that? Are you *@3$ Crazy!?
Fortunately, a bug bounty program can actually help improve the
security culture in your organization!
CHAPTER 2
This is a coordinated and purposeful dialogue
that you spearhead with a key internal
stakeholder: the engineering team.
As soon as you can, give your developers a heads
up that bugs are coming and that it’s a good thing.
Explain that any bug identified through your program
is live in production, and fortunately a friendly
hacker has taken the initiative to report it to you.
This means a malicious attacker could also find the
same bug, which creates real world motivation for
more timely remediation. It also helps to prioritize
and improve security culture throughout your
organization, and provides valuable data on where
your current security processes have failed (
(more
on this in Chapter 5, The Post Bounty Era).
Chapter 2.2: Allocate resources
Before you do anything else, lock down the resources necessary to get up
and running. This includes allocating time for yourself as well as securing
resources from your security team, and your immediate organization
Chapter 2.2.1: Choose a leader, build your team
First, you’ll need a bug bounty leader (BBL). This person is the ultimate
owner and champion for your bug bounty initiative. It might even be you!
The BBL is responsible for the success of your program, but they can’t
do it alone. Once the BBL is established, they need to form a bug bounty
team (BBT) that will support the ongoing program. The BBT is typically
composed of members of the security team, but there’s no reason you
can’t include other security-minded individuals from your organization.
P R O T I P :
Take charge of bugs with all the
right tools. To equip you, we’ve
created a sample Bug Bounty
Leader Job Description for you to
utilize in your organization.
1 2
CHAPTER 2
Chapter 2.2.2: Share the load
Running a bug bounty program requires a commitment from
your BBT to perform a large variety of tasks, such as triaging
bug reports, communicating with hackers, defining and dishing
out bounty amounts, vulnerability management, and more!
Many teams already have a full plate as part of their regular job duties,
so time management and batched work is the name of the game.
The best way to share the load is to set up a weekly on-duty rotation.