Please see this post before reading, for important caveats about the sources of information used to help construct this post.
Introduction
One of my favourite Security subjects is Bug Bounty Programmes, mainly because I was lucky enough to start work somewhere big enough to already have an internal programme in place and where I was wholeheartedly encouraged to get involved with its operation and help transform it into an external programme by its architect and implementer Dan Adams.
Internal Bug Bounty Programmes
The inspiration for this post came from this post on LinkedIn from the Product Security Engineering Manager of Lyft
As internal programmes are something I have experience with, but aren’t talked about publicly much, I figured it would make a decent blog post to start the New Year.
So, for those new to the idea of internal Bug Bounty Programmes, they are essentially private (invite-only) programmes, where invites are only available to staff members of the company offering the bounty payments (often an implicit blanket invite to all technical staff).
Doing this has some real big benefit and a few draw backs, so lets run through each in turn.
Learn as you go
Getting a Bug Bounty Programme right first time is very hard. An internal programme genuinely lets you develop robust processes and procedures ahead of an external launch.
If you’re upfront about the programme being a learning exercise then internal staff can be much more forgiving of slow triage, poor communication, vague or confusing scopes, and inconsistent or slow payments (all common problems with newly launched programmes). Making your internal hunters an important and valued part of your process can be the dividing line between “they listened to our feedback” and “they constantly keep moving the goalposts”.
Everything from your scope, your rules of engagement and your payment structure may need refining or even completely rewriting once you programme is live. That’s MUCH easier to achieve when it won’t cause disruption outside your organisation.
Flow Control
One lesson I learnt early from both Dan and from Bug Bounty Pioneer Katie Moussouris** is that one of the keys requirements of launching a bug bounty programme (or even knowing if you’re ready for one) is understanding your ability to handle the flow of incoming info the programme will bring. Having the resource to efficiently triage, remediate and pay bounties on new vulnerabilities is often a key differentiator between the launch of a successful programme and an embarrassing, expensive or unproductive one, but for many organisations launching as internal-only can limit that risk somewhat.
If you find you genuinely can’t keep up with the flood of new vulnerability reports, then being internal-only makes it much easier to change which classes of vulnerability are in-scope, refine the process or pause the programme altogether without upsetting the wider bug bounty community.
Unfair Advantage
When planning to launch a programme it’s not uncommon to lose sight of WHY you’re doing this. People try to create a fair and level playing-field so all hunters have the same chance of getting a bounty. If your aim is creating a challenge to find the best bug bounty hunter or simulate specific attacks then great, but it’s safe to say that ISN’T your aim. Most people are in it to collect the high quality vulnerability info they don’t already get from other sources, so why tie hunters hands behind the back.
The most successful internal programmes I’ve seem leverage the home-field advantage of internal hunters to go harder and deeper with less time wasted on dead ends by allow/encouraging hackers to review source code and design documents as well as going and talking with the development teams directly. Remember, even if you only care about public facing vulnerabilities and demand a PoC from a public network, that doesn’t mean your hunters need to be limited to doing their initial investigations from only public networks. It may be your website has a serious inject issue that’s currently mitigated by a WAF rule, but what happens when that rule is updated or you switch to a new vendor with a different vendor?
That said, it’s not uncommon to put the same Bounty Conditions on Internal hunters as you would on external ones, such as the vulnerabilities must be exploitable from the public internet.
Obviously achieving this may vary vastly from organisation to organisation, it’s not unusual for smaller organisations to have access controls that give all engineers the same flat access to all your source code repositories, design documents and network segments etc, but in larger organisations it may be necessary to allow hunters to apply to temporarily gain access to other teams’ resources to aid investigation.
Remember when it comes to paying, the value to you is in the information you receive, not the effort that was put into gaining that info, the fact internal hunters may have an unfair advantage and easier time doesn’t make their information any less valuable, so I’m therefore a big advocate of making internal payment structure identical to any external/public offerings you may have.
Dupes
One of the big annoyances for bug bounty hunters that has never really been addressed effectively is that of duplicate reports***. Most programmes only pay for the first reported instance of a vulnerability (otherwise not only are they paying for info they already have, but it would be possible for news of the vulnerability to pass from hunter to hunter) and understandably programmes don’t want to share publicly what vulnerabilities have been found but not yet fixed, so inevitably you end up with hunters using their time and talents to hunt down valid vulnerabilities, only to be told that they’ll get no reward as it’s already been reported.
In many cases internal programmes can lessen the pain, either by allowing staff to their internal bug trackers or encouraging communication between hunters and triagers can at least feedback if there have been reports for classes of vulnerabilities in the areas hunters are hunting.
Better Signal to Noise Ratio
Internal schemes can be much easier for internal triagers as the quality of the reports can be much higher and obtaining elaboration on unclear points can be so much easier to obtain.
Never underestimate the time that can be saved when the reporter has a decent understanding of your estate, the technology you use, your internal processes and your organisations general risk appetite. You tend to find that not only will you get high quality reports of the actual vulnerabilities, but often pointers to the source of the vulnerability.
Of course there will always be exceptions, but as a general rule internal reports are generally much quicker and easier to triage, contain much more info helpful to the team doing the remediation and contain far fewer false positives and incorrect assumptions.
Subterfuge and collusion
Whenever I talk about internal programmes the first question is “How do you stop people adding bugs so they can report them?”.
Whilst a rule that nobody can report any problem in a part of the code base they’ve worked on (or in some cases they were part of a team that worked on that area) is common, the real answer is much more cultural. Do you have a hiring policy that would attract people who would risk their employment and their reputation for a few thousand dollars in bounty payments?
The cons
So far I feel I’ve put forward a fairly compelling case that if you are in a position to launch a programme, start it as internal only, but what about the cons?
Over burdening hunters. Bug Bounty Hunting is fun, but it can also be infuriating, stressful and time consuming. Do you want your engineers spending all their free time thinking about finding vulnerabilities in your codebase? Or do you want them to switch off and think about something else entirely? Are you confident they’ll limit their hunting to just their free time, or will they actually be picking up a second job that impacts their first once. However, as with “Subterfuge and Collusion” if you feel this might be a problem, are you hiring the right people?
Rapidly Declining Interest. Whilst a new internal programme may introduce many new people to the world of bug bounty hunting, for the majority of people interest will wane over time and the flow of new vulnerability info will reduce. Things like short term incentives and events like charity hack days can garner increased participation but at some point it’ll stop being the cool and new thing and you’ll have to start looking externally for new participants.
Disillusioning external hunters. Bug Bounty hunters hanker for new programmes where all the low hanging fruit has been hoovered up and everything the find isn’t already reported and therefore a dupe. So, when you’re ready to move from internal to external, having it known amongst external hunters that your programme has already been ravaged by bug hunters and there the effort/reward balance will be more favourable elsewhere
Final Tips
Don’t launch an Internal Bug Bounty Programme, build an internal Bug Hunting Community, with the programme at the heart of it.
Plan for the future, always ask yourself “Would this also be Ok if the programme was a public one?”
Fix problems at source. It’s easy to use the Bug Bounty Programme as a ticket creation factory, but ensure you’re collecting data on the root cause of vulnerabilities and feeding that data back into the SDLC
Define your metrics, goal and reporting from the start. Even internal Programmes are expensive to run, so ensure you can prove the value of the scheme. Remember knowing about 1000 unmitigated make you at no less risk the knowing about 10 unmitigated ones, be able to prove programme is actually lowering risk.
Make the journey from your Bug Bounty Platform as frictionless as possible, so people choose to report things via the bug bounty platform, even if they are not sure if they actually qualify for bounties, rather have them sat on bugs where they can see something isn’t right, but can’t exploit it in a way that would guarantee a bounty
Don’t be afraid to change things. Launching as an Internal Programme gives you more freedom to change things that aren’t working as well as you’d hoped, use that to your advantage.
* You’ll notice that when referring to Bug Bounty Programmes I use the older English (British) spelling of the word Programme, but when referring to computer Programs I use the newer (US) one. This is intentional, though I can’t really justify it, other than I’ve always felt it was correct
** If you’re interested in Bug Bounties and you don’t know who Katie is, stop reading now and go read everything she’s written on the subject first.
*** Whilst it doesn’t really help on-going programmes for their events (where certain sites are put in in-scope to a limited period to an invited set of hunters) HackerOne have an initial window (normally 1hr) where hackers can report all the low-hanging-fruit they found during reconnaissance before the event and they all the share the bounty payment, which is an interesting way to tackle the inevitable dupes where when of the best bounty hunters in the world are given the same target and some advanced warning.