Finding vulnerabilities in your own software is a full-time job. So what if you could get crowdfunding help from experienced security researchers? That’s exactly what bug bounty programs do: help organizations discover bugs and vulnerabilities before bad actors can.
To help organizations develop their own bug bounty programauthor and security researcher John Jackson wrote Corporate Cybersecurity: Risk Identification and Bug Bounty Program.
“I wanted to make sure everyone understood what was going on in a program and how things needed to be handled,” he said. “I got frustrated when program managers didn’t understand bugs, and on the other hand, I saw how the communication went between hackers and employees.”
Here Jackson provides tips for creating a bug bounty program, explains how it differs from a vulnerability disclosure program (VDP), discusses issues to consider when developing a bug bounty against VPD, and more.
Check out an excerpt from Enterprise Cybersecurity for information on how to handle out-of-scope bug bounty submissions.
Editor’s note: The following interview has been edited for brevity and clarity.
Who would benefit from reading Enterprise Cybersecurity?
John Jackson: Organizations that have vulnerability disclosure programs looking to get further into the paid disclosure space of bug bounty programs or organizations that are looking to start small with bug bounty programs. Specific roles that would benefit include application security engineers, bug bounty program managers, and C-level people who need to understand how a bug bounty fits into the organization. It also doesn’t hurt to have pirates read the book.
Are there more bug or VDP bounty programs today?
Jackson: I would say there are definitely more vulnerability disclosure programs. Surprisingly, when I was researching for this book, I learned that many wealthy companies, such as Ford, a Fortune 10 company, and Adobe, have VDPs but no bug bounty programs.
What are the benefits of having a VDP instead of a bug bounty program?
Jackson: There are pros and cons to running a VDP versus running a bug bounty program. Vulnerability disclosure programs suffer from two things, one being resources. Because you are not responsible for paying a hacker and expect them to report it in good faith, the expectation on the program side of the house is that whatever is discovered is put on the back burner. Most of the time when you report to a vulnerability disclosure program, there might be a critical bug that goes unresolved for three months, four months, a year. This is not uncommon; I have already seen it. Moreover, the communication between the VDP and the hacker is random. Communication between a bug bounty program and a hacker is more efficient because it is handled by an intermediary, aka the trier.
However, the one thing you don’t get with bug bounty programs is the full disclosure experience because most of the time what the company pays is for you to report under NDA [nondisclosure agreement] so he can fix the bug and move on. Many of them do not allow public disclosures. The trade-off between VDPs and bug bounty programs is the difference between money and culture.
What advice do you have for companies considering launching a VDP or bug bounty program?
Jackson: There are a total of four different types of programs: public or private bug bounty and public or private VDP. The difference between them is cost and visibility.
My recommendation would be to start with a small private bug bounty program and expand the scope quarterly. Always look to expand the scope until all your major assets are covered. If you’re starting with a generic scope and you’re new to bug bounty programs, you’re just going to be bogged down with submissions. Usually bug bounty platform providers [e.g., HackerOne or Bugcrowd] allow you to give them a target number of hackers to invite per month or per quarter, and you establish a cadence with them.
The reason I didn’t suggest VDP is that many businesses are trapped in a loop. They have a VDP, and whether it’s public or private, they get constant bug submissions. They start saying, ‘Why pay for bugs? Why pay for vulnerabilities?’ They miss the big picture, meaning they won’t get the thoroughness that comes from hackers motivated to make money from a bug bounty program.
What advice would you give to companies launching a bug bounty program?
Jackson: I have a some different immediate tips that come to mind. Make sure all aspects of your security are covered. For example, if you are a heavy web application, have things like load balancers, web application firewalls, and endpoint detection and response. [EDR] tooling. With app coverage and EDR out of the way, you also want to involve an attorney to make sure your purposes are covered in case something happens to the bug bounty program. Accountability is important.
Once the security controls are in place, the next step is to do things like internal and external penetration testing. Cover while having a basic level of security to ensure you don’t go broke immediately when you start the bug bounty program.
Also, make sure you have application security engineers ready to handle the submission workload that a bug bounty program brings. Have a program manager to sort through submissions. You need someone who understands the seriousness of the vulnerabilities submitted. When I was a program manager, I saw bugs being closed in reports I looked at and said, “No, that’s legit.” The bug seems pretty serious and we should look into it further. From there I would pull it into an open state and sort it. Program managers must exercise due diligence. Have program managers who at least understand the different types of vulnerabilities, especially in web applications.
Another tip is to run a private program first. This way you can start with a smaller amount of target assets that are in scope. From there, expand the scope quarter by quarter until everything is covered.
What are the main issues that arise when companies create a bug bounty program?
Jackson: Confusion and paranoia. With bug bounty programs, you will have a higher amount of pen test traffic because hackers are constantly testing your application. This can be frustrating because you want to determine if this traffic is from criminals trying to get in or just hackers testing your systems. But that’s just overthinking. Do not try to determine if it is a security researcher or a criminal; just try to stop the hacker. If someone is accessing your network, can you stop them? How are you going to stop them? You must go through the chain of custody process no matter what.
To make things easier, program managers can email security researchers through their bug bounty platform and ask if anyone has tested something that they’ve seen an increase in traffic for. Just ask that they contact you if they have tested any web shells etc. and then you can identify the traffic by source IP addresses. Another option to find out if it is a security researcher or an attacker is to provide a VPN for testers to use.
Having a SIEM is crucial if you are going to run a bug bounty program. It would ingest all logs of any asset you want to test. You can view source IP addresses to see who is doing what.
How do you recommend security researchers start working on bug bounty?
Jackson: When you start out as a researcher, you try to figure it all out and figure it out. Don’t be put off by big companies – for example, Hulu or Google – that have a lot of assets. Having more assets means there’s a good chance you’ll find more vulnerabilities. Too often, researchers target public bug bounty programs of medium or small size when starting out. It’s the worst thing you can do — you want to find the biggest public programs. With these, many hackers probably run automated scans and do not get their hands on the targets. If you want to get more private invitations, familiarize yourself with specific applications and network resources, and test them thoroughly.
The other thing researchers need to think about is the impact of different types of bugs. Also, you need to be thorough in reporting. You need to understand how to maximize impact and not get frustrated. For example, you may discover that remote code execution is possible, but it may just be a lagging development server that is not connected to the network at all, which means that the impact is much lower.
About the Author
John Jackson is a senior offensive security consultant and founder of Sakura Samurai 桜の侍, a hacking group dedicated to legal hacking. He is best known for his multiple contributions to CVE security and government/corporate research. Jackson has contributed to the threats and vulnerabilities space, disclosing several cyber vulnerability research and helping with resolution for the greater good. He continues to work on several projects and collaborates with other researchers to identify key cyber vulnerabilities.