Information Security at Nasdaq

In 2023, many organizations run a bug bounty program. Whether it’s a responsible disclosure program or an actual bug bounty program where bounties are rewarded to researchers, companies are seeing the benefits of running such programs as their assets end up being more secure and it reduces the overall risk, which is technically the end goal, we want to minimize the risks as much as possible.

Running a successful bug bounty program definitely has a high cost associated with it. As an example, just in 2022, Google reported paying over $12M in bug bounties, and this amount doesn’t even include the hours spent by their employees. However, we don’t all need to spend that much money to have a successful bug bounty program. A smaller company with a lower budget and resources can still be quite successful, it’s simply a matter of being organizationally ready.

How does one get ready? Well, we could start off by doing a cost-benefit analysis to determine whether running a bug bounty program is actually worth it in the first place. The cost of reducing the risk may be more than the value of the assets themselves, so why try and mitigate the risk if that’s the case? If it is determined that it is worth it and that you’d like to get your feet wet, there are a few components we need to apply or evaluate the readiness to determine if your organization is ready or not to go ahead and launch a bug bounty program.

1. As always, we need senior management approval as they need to know that external researchers will poke around their assets and try to hack into them.

2. Companies need to have an up-to-date inventory of their assets, owners, etc., a good asset management practice in general.

3. Roles and responsibilities need to be clearly defined so that you know who will triage and reproduce vulnerability reports, who will suggest fixes to the engineering teams, who validate the fixes, who is responsible for identifying if the vulnerable code is used elsewhere, who has the responsibility of paying out the reports, so on and so forth.

“A smaller company with a lower budget and resources can still be quite successful, it’s simply a matter of being organizationally ready”

4. Similarly, to the previous point, employees who are new to running a bug bounty program may need training. This goes from developers learning the many types of vulnerabilities out there to security engineers learning new tools to reproduce researcher's reports.

5. Management needs to do proper capacity planning as running a bug bounty program typically involves getting more work, so we need to make sure our team is ready to support that extra work.

6. To avoid getting bombarded with reports from the get-go, we need to make sure our PDLC/SDLC is as robust as possible so that it includes automation and tools such as SAST, DAST, SCA scanning, vulnerability scanning, etc. That way, most of the low-hanging fruit vulnerabilities should be fixed before launching the program and let the researchers use their creativity to find bugs that your tools weren’t able to find.

7. If the scope of the program is going to be small and that time and budget allow it, having a penetration test done is a good idea as it’ll give us an idea of what our current posture looks like.

8. Even if bug bounty hunters are technically ethical hackers, having a SOC monitoring their traffic is still a good idea. They may access confidential and restricted information without really realising that it’s sensitive so having a team that would be able to detect and block that traffic is ideal.

9. To add to the previous point, if it is determined that a security event becomes an incident, we need an incident response plan to properly deal with the incident.

10. Finally, we need to have a bug bounty program policy to put in the rules of engagement on what researchers can and cannot do, the scope of the program, the expected bounty amounts, the safe harbour, and all other details that we believe should be shared in the policy.

Considering bug bounty is still rather new, there isn’t any framework or standard that exists that organizations can rely on to build a successful bug bounty program. That said, all of the above aren’t necessarily requirements, every company is different, but I believe these are best practices that should be followed for the process to be as smooth as possible. With time, you’ll be able to gather metrics, create KPIs and OKRs and improve the procedures, workflows, etc. Do keep in mind that, running a successful bug bounty program requires preparation and teamwork from all parties involved.