Organisations of various sizes have been putting together and hosting
bug bounties over the years. Some of these are very popular - the
participants look forward to the event on their calendars. Others, not
so much. The “hit or miss” nature of these events are sometimes a
deterrent for any new business thinking about hosting a bug bounty.
And yet it is somewhat easy to plan for success - using playbook-like
approaches and strong ownership of the process. Hasgeek has invited
showrunners of some of the most successful bug bounties to share
insights, secrets and tips which would help any business get started
with this approach. Blending talks, how tos and a panel - this is the
“get started with bug bounties” you were looking forward to

Hosted by

Rootconf is a forum for discussions about DevOps, infrastructure management, IT operations, systems engineering, SRE and security (from infrastructure defence perspective). more

Shrutirupa Banerjiee

@shrutirupa

Prerequisites to create a bug bounty program

Submitted Nov 24, 2022

A bug bounty program could be one solution to maintaining a good security culture in an organization; however, building one could be challenging. Now that we are clear on the importance of the Bug Bounty program(link) let’s comprehend the essential prerequisites the company should follow.

There are mainly two types of bug bounty programs-
Private
Public

Running a private bug bounty program indicates having a limited number of researchers who can participate. In contrast, a public bug bounty program allows individuals to participate and submit their reports. So, to begin with, an organization needs to identify which type of program they would like to go ahead with. If the organization needs to be more confident in holding a public program to allow all kinds of researchers, they can start with the private one. Either of the programs can be run in the long term; the only difference that it makes is the participation of the researchers. Also, in private ones, only the researchers who have participated will be able to know and work on the scope of the application. Whichever type 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 program will be provided limited URLs or APIs that they are allowed to test. These limitations define the scope of an application. Researching or finding any bug beyond the scope is not counted as a valid one. So, an organization holding a bug bounty program should ensure that the application’s scope is already mentioned in the platform so that only valid submissions are considered.

Once figuring out the type of the program, the organization must decide whether to use an already existing bug bounty platform such as HackerOne, BugCrowd or Integrity, etc, or build one for themselves. If they have enough resources to build a platform from scratch and maintain it in the future, they can go ahead with their one. Evaluating this thought before commencing a bug bounty program is necessary as there would be a continuous payment or rewards(bounty) being 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 should be to identify if the submission is valid. On what criteria can we decide if the vulnerability is critical or informational? In case it turns out to be valid, how should the organization identify paying bounties to them? What should be the payment method? Will there be any swags too given to the researchers? The financial aspect should be decent enough to provide rewards to the researchers. There should be an active finance team that can take care of this scenario.

A proper internal security team is not just to test the applications before putting them on the bug bounty platform, but they have a huge responsibility too. The team should promptly take up the responsibility of validating those reports and responding to the researchers as soon as possible. There should also be an acknowledgement mail to 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, it should be made sure that the resources to remediate the vulnerability are available too. Basically, the remediation infrastructure should be in place.

There could be a scenario where the internal security team has found a vulnerability. In that case, it should be mentioned over the platform that the team is currently working on this issue. The researchers should not be submitting the same vulnerability report again. The same could be mentioned beforehand for the out-of-scope and acceptable risk-based scenarios.

An organization ready to host its bug bounty program is taking a big step towards implementing a healthy security environment. However, certain factors should always be kept in mind. The points may seem quite basic, yet important as if not properly managed and organized, this could be highly challenging.

Comments

{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Hosted by

Rootconf is a forum for discussions about DevOps, infrastructure management, IT operations, systems engineering, SRE and security (from infrastructure defence perspective). more