Setting up a bug bounty programme in your organization

Starting a Bug Bounty programme can be a tedious task. Yet, it is important for the security engineering culture of the organization. It adds another layer of security to an organization’s infrastructure.
Now that you understand the Whys and Whats of bug bounty programmes, let’s dive a little deeper into how to start one. I will deduce the elements that should be considered before an organization launches a bug bounty programme. I have already discussed the very first step in the previous blog post, which is identifying the type of programme that the organization is willing to work on, i.e., public or private, and the platform to use - whether an already available one or self-hosted.

How will an organization identify if it is ready yet?

This question can be answered in two parts:

• Availability of resources
• Management of resources

The organization should be well acquainted with the resources available for the programme. This is one of the essential aspects to be assessed. Understanding of the resources should be both from the reporters’ and the reportee’s point of view. It should be easier and clearer on the reporter’s side how to identify the scope and submit their report(s) if any vulnerability is found. On the other hand, the resources should be readily available on the reportee’s side for quick response and check on the submitted report.
Availability of resources themselves is not enough for running a successful bug bounty programme. Effective management of resources can help here. Whenever a report is submitted, who is responsible for evaluating the report or how is the evaluation decided? These are examples of some aspects around resources that should be evaluated.

The organization should be well aware of the shortcomings of its resources and identify how to take care of the scenarios. This will help the organizations with the management of the bounty later, after a successful vulnerability is found by a researcher.

What kind of resources are involved here?

Resources are everything that are required to build a complete bug bounty programme. For instance, the website, the platform, the storage, reports, the bounty, and the team.

These resources should be well managed and taken care of, especially if there is any kind of subscription that has been taken. They are highly required to build a successful bug bounty programme which revolves around the following facets:

• Scope of the application - the platform the organization will use should have all the details related to the scope of the application. The researchers should be able to clearly understand the scope and how to go ahead with the analysis of it. There should also be mention of the fact that if the researchers are working outside the scope, their reports will be considered invalid. The policies and rules should be clearly stated, and there should be a team identified to take care of these aspects.

• Report - whenever a researcher finds a vulnerability, there should be a suitable format that needs to be followed. And this can be done in the form of a report. The organization must decide how the report should be submitted to its platform. Do the researchers need to send an email to the respective team or should there be an option to submit their report? The report can either be a type of form on the organization’s platform, or it can be a document type that can be uploaded to the platform. This should be mentioned beforehand. There should be a dedicated team to validate the report that can be segregated into four parts:

1. Valid report - this has a valid vulnerability which has been submitted for the first time. This will be further classified based on priorities so that bounties can be given basis these reports.
2. Duplicate report - this has a valid vulnerability but has been submitted by somebody else before.
3. Out-of-scope report - this has a vulnerability that is present in that part of the application which is out of scope for the current bug bounty programme.
4. Acceptable risk - if the organization is aware of the vulnerability and thinks of it as an acceptable risk.

Another essential point to note is how can a researcher define the criticality or the validity of the vulnerability while submitting the report.

1. P1 (Critical) - if the vulnerability is exploitable without any user intervention that can disrupt the business value completely, like confidential data leakage or any malware attack.
2. P2 (High) - if the vulnerability is exploitable only when there is a user intervention. This disrupts the business value to a greater extent too.
3. P3 (Medium) - If the vulnerability is exploitable with the help of user intervention, but may not disrupt the business value too much.
4. P4 (Low) - the vulnerability is non-exploitable.

The levels can be defined by the organization based on how much the scope adds value to the business. The policies behind the validation and criticality of the report should also be mentioned on the platform so that the researchers can comprehend the workflow.

If the report submitted is valid and is at any of the above-mentioned risks, the team who can start working on mitigating the vulnerability should be ready to do their mitigation work as soon as possible.

• Communication: there should be an appropriate communication channel for the researchers and the respective teams. The organization should be ready with how the communication will be done with the researchers. This can start with sending acknowledgement emails to the reporters who have just submitted the report. It will be easier if the communication can be automated. Further, the researcher and the internal security team should be able to communicate through chats or calls (if required), to understand the vulnerability and the risk entirely. This will help with the immediate next task of mitigation. Also, if the report is valid or invalid, it should be adequately communicated with the researchers. The organization should take care of these small nuances to avoid any kind of communication gap.

• Payment of bounty: if the report submitted is valid, there should be an accurate team who is taking care of all the payments. The platform to make the payment should also be defined in the earlier stage. For example, if the organization is planning to make the payment through PayPal, it should take the details from the researchers beforehand in order to complete the payment.
  In case of any discrepancies during payment, the team should be readily available to sort out the issues.
  The organization should take care of the fact that they have enough resources to pay the required amount whenever a vulnerability is found.

The building-up of the programme takes a lot of time. However, the rest works out fine if the resources are well managed and the teams are well aware of their roles and responsibilities.