It really depends on what you're looking to offer and receive out of your bug bounty program. There are differences between a public and private bug bounty; normally, we see programs start as private, and then work their way into public. This isn't always the case, but most of the time, organizations will open a private bug bounty by inviting a subset of security researchers in order to test the waters, before having it publically available to the community.
There are a few things to consider before launching a public bug bounty. There's going to be a testing period with your application, and before you call down the thunder from the internet abroad, it's wise to work with a group of skilled researchers or an organization that specializes in this area to validate your processes and procedures.
Many times, organizations aren't comfortable with opening this to the public, and they tend to limit the scope of the testing and those that can test it; your risk appetitive will reduce the amount of tests, and also limit the vulnerabilities that can be found within the application. Many organizations want to validate their security posture, use external resources to test their security and supplement this testing to find vulnerabilities before they're found by malicious actors.
Before flipping from a private to a public bug bounty program, there are a few things to consider. First, open the program to researchers or organizations that are tested and trusted. You don't want to go to just anyone right away, as vulnerabilities could cost you your reputation and revenue if they are found.
Since many of these researchers are doing this for financial gain, you need to have a firm grip on your payout structure within the private bug bounty to better understand how to use it if it goes public. Are your applications so insecure that you'll be paying out numerous bounties at a high rate? Understanding your payout structure upfront will help you maintain a manageable bug bounty program.
Before you go public with a bug bounty program, you also need to have a good reason to have the program public. What is the end goal of the program going public versus keeping it private? If you want to find vulnerabilities, and you have a process to do this internally, then maybe a private vulnerability program is right for you. If you already have a vulnerability management process in line and are performing static and dynamic analysis, but want to supplement that with additional manual testing from a larger community, then public testing might be what you're looking for.
Lastly, it's very important to have a bug bounty rules of engagement page on your site or application to let participants know how to act, what to expect and the rewards for each bug. It will also help to let researchers know what to expect when it comes to how bugs should be submitted using responsible disclosure practices.
Many sites have bug bounties now, but just because you open it publically doesn't mean you'll have a horde of white hat hackers crashing through your site to search for bugs. Determining what the best bounty is, the section of the code that you'd like to test and how to act operationally when you start seeing attacks occur is important to your bug bounty submissions and your overall day-to-day operations.
Read the rest of my article here: http://searchsecurity.techtarget.com/answer/How-does-a-private-bug-bounty-program-compare-to-a-public-program
No comments:
Post a Comment