Part Three: Bug Bounty  Programs —  Is Your Organization Ready?

This piece is the final 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.

Last year, Okta announced that we launched a public bug bounty program with Bugcrowd. I’ve already written about the early considerations necessary to successfully implementing a public bug bounty program and who you should involve in the process, now I’ll share what you should think of as final deliberations and steps.

Setup the product infrastructure: If your company has a freemium product or if your users are the product, then it is easier to deliver something for testing to the researchers. They probably already use it in their daily lives. If you have an enterprise product, you will have to think through how to provision a full-featured paid product for free to a bunch of bounty hunter unattributed acronyms and how to sell that to your internal profit centre teams. Don’t get into the discussion of internalising this cost as the cost of running a bug bounty program or you will never achieve good ROI. Hopefully, you have testing environments that can be leveraged. If not, you might want to figure out how to expire or delete provisioned accounts after a set amount of time or inactivity.

Setup security monitoring: You are inviting people who break things for a living, to come and have a look at your house. Don’t take that lightly. Also, for bug bounties there is zero or little attribution to actions taken by researchers. The only resort you have is working with the bug bounty platform to ban a researcher. Hopefully, you have a mature security monitoring posture that can help you detect over ambitious individuals.

Build relationships with researchers: Think of the program as a partnership and not as a service you pay for. From timeliness of your responses, to being just in your severity assessments and explaining your thought process behind your severity ratings, all play a crucial role in defining the relationship you will have with the researchers. Be aware of how your actions impact the morale and motivation of researchers. As with any partnership, you want to be transparent and considerate to get the best value.

Finally, secure your human perimeter: There is a good chance that your reception desk or your tier-1 support staff will be targeted via some form of social engineering. Talk to the rank & file and leadership of these teams and make them aware. Ideally you are doing this and many of the above as part of your normal security education.

How do you know when you are ready. I mean really, really ready?

• Do you have a tried and tested vulnerability management process?

• How many high or critical vulnerabilities were identified in recent external pen test reports?

• How quickly can your engineering team fix critical bugs?

• Is your executive management supporting a public launch?

• Are you confident of more external eyeballs on the security of your product?

Once you have reasonable answers to some or all of the above questions, whether you are Google or a 10-person startup, you will have to take a leap of faith. There is no ideal time to go public with your bug bounty program. There is no ideal time to get PWNed either. Hopefully, your public bug bounty can help you identify vulnerabilities before others do!

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.