Part One: Bug Bounty  Programs —  Is Your Organisation Ready?

This piece is the first in a series of three blog posts on bug bounty programs and what are some considerations to think about when investing in or launching the program.

Bug bounty program delivery models range from self-managed input channels for receiving vulnerabilities, platform managed private programs with a small curated list of researchers, scope restricted and time boxed engagements to an all out public bug bounty program.

The right delivery model for your company depends on the goals defined for the program, which can change over time and similarly vary from:

1. Validating security posture of your product and your internal security team

2. Augmenting breadth of internal penetration testing efforts

3. Incentivising and opening up a channel for receiving vulnerabilities

4. Building trust with customers & prospects

5. Enhancing the security perception of your company

6. Leveraging the external visibility to improve internal time2fix metrics

7. For “fear of missing out”, also commonly referred to as FOMO

8. Establishing and building a relationship with the security researcher community

9. Help source and hire security talent

10. As a payment and tracking platform to reward submissions you received via other channels

11. etc

In most cases bug bounty programs are initiated due to one or all of the above reasons. Regardless, to efficiently crowd source your internal vulnerability finding efforts and derive demonstrable value, it is oftentimes necessary to roll out a public bug bounty program. Here are a few things to consider when considering a public bug bounty investment:

Test the waters: Ideally, don’t launch a public bug bounty before you have fine tuned your variables. A private program allows you to do exactly that. Start small, increase researcher counts every quarter and play with your payout ranges every quarter for a year or more to get a good handle on your internal state of maturity. Use this time to fine tune your payout ranges.

Defining bug bounty goals, before deciding on launching a public program: It is important to define what you want to get out of a public bug bounty. Your goals will not only shape some of your readiness activity, but it can also help you decide if you want to go public at all. Only 30% of bug bounty programs go public. If cheaply finding bugs is all you care about, then maybe a private program is more suitable and less of a hassle. On the other hand if you want to augment your internal team and get breadth/depth of testing coverage, a small private pool of researchers might not get you that (researchers jump ship fast, and the time they spend on each bounty is limited).

Implement a vulnerability management process: Sounds weird in today's day and age, but if you don’t have a vulnerability management process or if your engineering leadership is not on-board with that process or if your SLAs are too loose or rarely enforced, stop and don’t launch. There is no easy way to say this: If you can’t get your internal teams to fix bugs in time, there is no reason to go out looking for bugs.

Nail down the rules_ of_game on your landing page: This is arguably the most crucial step you can take. Spend time and effort into drafting your landing page. The more you sweat in peace, the less you bleed in a war.

• Scope definitions for properties and submissions define the target area for testing. The definitions might not stop researchers from checking out your out of scope support portal, but it will definitely help stop them from submitting every occurrence of a 500 HTTP Response. It is difficult to shoot at a moving target and hence frequent changes to your rules are not desirable. However, don’t consider the scope of the program as a long-term static variable. If your product has a good security posture, be open to gradually scoping-in other attack surface of your organisation.
• Illustrative examples and respective payouts will serve as a bedrock and guide payout decision making. Use variance in payouts to orient what you want researchers to spend most of their effort on finding. When dealing with researchers, granular and exhaustive examples could box you in your own definitions, so maintain the fine balance between too much and too little.
• API and setup documentation is necessary for complicated enterprise products. Everyone knows how to use a social media app but it takes time and guidance to set up an Active Directory infrastructure. Without well documented guidance, researchers will quickly lose interest and move on.

Experiment with your payout ranges before launch: This is where having a private program allows you to get a head start. Researcher interest is very fickle. Unless the name of your company starts with a G (oogle), a F (acebook) or an A (pple), you will have to fight for attention. Apart from your company’s brand, the payout range (both lower and upper bounds) has significant impact on the quantity and quality of submissions you are going to receive. There is good evidence to suggest that a high lowermost bound is much more impactful for quantity of submissions than a high upper bound, whereas a high upper bound can incentivise researchers to spend longer durations testing specific areas of your product or testing specific class of vulnerabilities. Not all researchers care about money, but many do. Use it.

For more considerations, visit the Okta blog next week for the second instalment.

Disclaimer: This article only illustrate some of the things an organisation needs to think about when considering a bug bounty program. Each environment and situation is different. The article should not be taken as an exhaustive list of diligence items, recommendations or a set of best practices.