5 Things NOT To Do With Bug Bounties
I’ve put together a quick list of things NOT to do when working with a security researcher in an official or unofficial bug bounties. This is based on personal experience, but also on the follies I’ve seen other companies commit.
Table of Contents
- Do Not Ignore Security Researchers
- Do Not Refuse to Reward Security Researchers If You Took An Action
- Do Not Lawyer Up or Threaten Security Researchers
- Do Not Just Address The Symptoms
- Do Not Starve Your Bug Bounty Program
1. Do Not Ignore Security Researchers
Believe it or not, security researchers are on your side (for the most part). Although they may be financially motivated or looking to build some credibility among their peers, at the end of the day, they have highlighted an issue they feel is a security risk and that probably needs attention.
If you know about the vulnerability already, great… just let them know! It’s proper etiquette, and ignoring could make the problem worse or they may publicly disclose it. Familiarize yourself with the general responsible disclosure etiquette out there. Here are some links to examples or more information about responsible disclosures:
2. Do Not Refuse to Reward Security Researchers If You Took An Action
If you ended up taking any internal action to address a vulnerability a researcher has reported, you should reward them. Depending on the severity of the issue, it can be something small like a gift card, or something larger well into the thousands of dollars. Take a look around at how other companies similar to yours reward for their bug bounties and come up with something appropriate to your company.
3. Do Not Lawyer Up or Threaten Security Researchers
This is probably the most common mistake made by companies completely unaware of the world of bug bounties. Even PWC threatened a bug bounty researcher with a cease and desist, which was an embarrassment for the information security community. Many companies not used to the bug bounties react very harshly to researchers trying to point out vulnerabilities in their software, often for no gain at all. Jared Folkins and others created OpSecEdu.com to protect security researchers from Education Software companies harassing researchers.
Unless you are being threatened or harassed, treat the security researcher bringing this information to you as an ally.
4. Do Not Just Address The Symptoms
When looking to solve a security vulnerability, it is important to address the underlying issue or root cause, and not just superficially manage the symptoms.
One reason is that although the security researcher may have altruistic reasons for reporting, there could be other bugs they are sitting on caused by the same issue, where they’re waiting to report and cash in. They may be working in groups, so you will not always see it reported by the same person.
Another obvious reason is to improve the security of your infrastructure or application. For additional work of solving the root cause, you may have addressed a whole class of undiscovered security vulnerabilities, saving you from lots of pain or shame down the road.
5. Do Not Starve Your Bug Bounty Program
If you don’t have a Bug Bounty Program, consider starting one. At the very least, you should have a security@ email address going to the right people in your organization.
If you do have a Bug Bounty Program, make sure you are keeping your response times low. Also, revisit your bug bounty reward structure and make sure it’s competitive enough with today’s standards.
If you don’t have all your apps in your bug bounties, consider adding additional ones. Unless your apps are not being used publicly, there should be a good reason why there isn’t any coverage from a bug bounty perspective.
Bug Bounty Programs need a lot of care and feeding, but they are an excellent security investment and multiply in return. In another article, I will outline how to stand up a fully functional Bug Bounty Program.