Setting up a bug bounty programme in your organization

A bug bounty programme can be one of the solutions to maintain a good security culture in your organization. However, building a bug bounty programme can be challenging. Now that we are clear about the importance of the setting up a bug bounty programme, let us look at the essential prerequisites the a company should follow when setting up such a programme.

There are mainly two types of bug bounty programmes:

• Private
• Public

Running a private bug bounty programme indicates having a limited number of researchers who can participate. In contrast, a public bug bounty programme allows individuals to participate and submit their reports. To begin with, an organization needs to identify which type of programme they want to go ahead with. If the organization requires more confidence to run a public programme to allow all kinds of researchers to participate, they can start with the private one. Either of the programmes can be run in the long-term; the only difference that it makes is the participation of external researchers. Also, in private bug bounty programmes, only the researchers who have participated will be able to know and work on the scope of the application. Which ever type of programme is chosen, the scope of the application is another aspect that needs to be kept in mind.

What do we mean by the scope of an application?

The researchers participating in the programme are provided limited URLs or APIs that they can test. These limitations define the scope of an application. Researching or finding any bug beyond the scope is not counted as a valid one. An organization holding a bug bounty programme must ensure that the application’s scope is already mentioned in the platform so that only valid submissions are considered.

Once the organization has decided on type of bug bounty programme, it must also decide whether to use an already existing bug bounty platform such as HackerOne, BugCrowd or Intigriti, etc, or build one for themselves. The organization can build its own bug bounty reporting platform if it has enough resources to build such a platform from scratch and maintain it in the future. Evaluating this thought before commencing a bug bounty programme is necessary as there will be a continuous payment or rewards (i.e., bounty) that is given to the researchers, whenever a valid submission is made.

Apart from having enough resources to set up a platform, it is equally important to take care of the process required post submission of a vulnerability. For example, once a submission is made, the first thing is to identify if the submission is valid. What are the criteria for deciding if the vulnerability is critical or informational? In case it turns out to be valid, how will the organization identify payment of bounties to the researchers? What should be the payment method? Will any swag be given to the researchers? The financial aspect/monetary reward should be decent enough to incentivize researchers. The organization must also have a proactive and responsive finance team to take care of payments.

A proper internal security team is not just to test the applications before putting them on the bug bounty platform. They also have a huge responsibility too. The team should promptly take up the responsibility of validating the bug reports, and responding to the researchers as soon as possible. An acknowledgement mail must be sent back to the researchers who submitted any vulnerability. There should also be an appropriate platform for regular conversations with the researchers.

If a valid report is submitted, make sure that the resources to remediate the vulnerability are available too. This means that the remediation infrastructure should already be in place while launching the bug bounty programme.

There can be a scenario where the internal security team has found a vulnerability. In that case, it must be mentioned over the platform that the team is currently working on this issue. The will prevent external researchers from submitting the same vulnerability report again. The same can be mentioned beforehand for out-of-scope and acceptable risk-based scenarios.
An organization ready to host its bug bounty programme is taking a big step towards implementing a healthy security environment. However, certain factors should always be kept in mind. These points may seem quite basic, yet they are important. If not properly managed and organized, the scenarios after launching a bug bounty programme can be highly challenging.

References

1. Links to the slides for the talk by Joy B. and Pankaj Mouriya are available here.