Application Security

An enterprise bug bounty program vs. VDP: which is better?

An enterprise bug bounty program vs. VDP: which is better?
Written by ga_dahmani
An enterprise bug bounty program vs. VDP: which is better?

Discovering vulnerabilities in your own software is a full-time job. So what if you could get help from experienced crowdfunded security researchers? Bug bounty programs do exactly that: They give organizations a helping hand in discovering bugs and vulnerabilities before the bad guys can.

To help organizations develop your own bug bounty programwrote author and security researcher John Jackson Corporate cybersecurity: risk identification and the Bug Bounty program.

“I wanted to make sure everyone understood what goes on in a show and how things should be run,” he said. “I would get frustrated when bugs weren’t understood by program managers and on the other hand how it was communicated between hackers and employees.”

Here, Jackson offers 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 vs. VPD, and more.

See an excerpt from Corporate Cybersecurity for information on handling out-of-scope bug bounty submissions.

Publisher’s note: The following interview has been edited to be concise and clear.

Who would benefit from reading? Corporate Cybersecurity?

Cover image of Corporate CybersecurityClick for more information on


Corporate Cybersecurity:
Risk Identification and
Bug bounty program
.

John Jackson: Organizations that have vulnerability disclosure programs and are looking to get more 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 individuals who need to understand how a bug bounty fits into the organization. It also doesn’t hurt for hackers to read the book.

Are there more bug bounty programs or VDPs today?

Jackson: I would say there are definitely more vulnerability disclosure programs out there. Surprisingly, when I was researching 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 consequences of having a VDP instead of a bug bounty program?

Jackson: There are pros and cons to running a VDP compared to running a bug bounty program. Vulnerability disclosure programs suffer from a couple of things, one of which is resources. Because you are not responsible for paying a hacker and you expect them to report in good faith, the expectation on the program’s side of the house is that anything you discover is put on the backburner. Many times when you report to a vulnerability disclosure program, there may be a critical bug that goes unresolved for three months, four months, or a year. That’s not unusual; I have seen it before. Also, the communication between the VDP and the hacker is unpredictable. Communication between a bug bounty program and a hacker is more efficient because it is handled by an intermediary, also known as a triager.

However, the one thing you don’t get with bug bounty programs is the full disclosure experience because, many times, what the company pays is for you to report under NDA [nondisclosure agreement] so you can correct the mistake and move on. Many of them do not allow public disclosures. The tradeoff between VDPs and bug bounty programs is the difference between money and culture.

What advice do you have for companies considering starting a VDP or bug bounty program?

Jackson: There are a total of four different program types: public or private bug bounties 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 reach on a quarterly basis. Always look to expand the scope until you have all your major assets covered. If you start with a wildcard scope and are new to bug bounty programs, you will simply be overwhelmed with submissions. Typically, bug bounty platform providers [e.g., HackerOne or Bugcrowd] allows you to give them a target number of hackers to invite per month or quarter, and sets a cadence with them.

The reason I didn’t suggest a VDP is that many companies get caught in a loop. They have a VDP and, whether public or private, they get constantly sending bugs. They start saying, ‘Why pay for mistakes? Why pay for vulnerabilities?’ They miss the big picture, which is that they won’t get the thoroughness that comes from hackers motivated to make money through a bug bounty program.

What are some tips for 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 it’s a heavy web application, have things like load balancers, web application firewalls, and endpoint detection and response. [EDR] stamping With app and EDR coverage out of the way, you’ll also want to get involved legally to make sure your ends are covered in case something happens in the bug bounty program. Responsibility is important.

With security controls in place, the next step is to do things like internal and external penetration testing. Cover everything by having a basic level of security to make sure you don’t immediately go bankrupt when you launch 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 classify submissions. You need someone who understands the severity of the vulnerabilities submitted. When I was a program manager, I saw bugs being removed from reports I’d seen and said, ‘No, this is legit. The bug seems pretty serious, and we should look into it further. From there, I would bring it to an open state and evaluate it. Program administrators must do their due diligence. Have program managers who at least understand the different types of vulnerabilities, especially in web applications.

Another tip is to launch a private program first. This way you can start with a smaller number of target assets that are in scope. From there, expand the scope quarter by quarter until you cover everything.

What are some of the biggest issues that come up when companies create a bug bounty program?

Jackson: Confusion and paranoia. With bug bounty programs, you will have a higher amount of penetration testing traffic because hackers are continuously testing your application. This can be frustrating because you want to determine if this traffic is criminals trying to break in or just hackers probing your systems. But that’s just overthinking things. Don’t try to determine if he is a security researcher or a criminal; just try to stop the hacker. If someone enters your network, can you stop them? How are you going to stop them? You have to go through the chain of custody process, no matter what.

To make things easier, program admins can email security researchers through their bug bounty platform and ask if anyone has been testing something that they’ve seen increased traffic. Just ask them to contact you if they’ve been testing web shells etc, and then you’ll be able to identify the traffic by source IP. Another option to tell if you are a security researcher or an attacker is to provide a VPN that testers must use.

Having a SIEM is crucial if you are going to run a bug bounty program. It would ingest all the records of whatever assets you want to test. You could look at the source IPs to see who is doing what.

How do you recommend that security researchers start working on bug bounties?

Jackson: When you’re starting out as an investigator, you’re trying to figure everything out and figure things out. Don’t be put off by the bigger companies, say Hulu or Google, which have a lot of assets. Having more assets means there’s a good chance you’ll find more vulnerabilities. Too often, researchers point to medium or small public bug bounty programs when they start. That’s the worst thing you can do: you want to find the most important public programs. With that, many hackers are likely to run automatic scans and not get down to business with the targets. If you want more private invitations, get hands-on with specific applications and network assets, and test them thoroughly.

The other thing researchers need to think about is the impact of different types of errors. In addition, you must be thorough in reporting. You have to understand how to maximize impact and not get frustrated. For example, you may find that remote code execution is possible, but it could be a lagging development server that isn’t really connected to the network, meaning the impact is much smaller.

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 many contributions to enterprise/government security and CVE research. Jackson has contributed to the threat and vulnerability space, revealing various pieces of cyber vulnerability research and aiding in resolution for the greater good. He continues to work on various projects and collaborates with other researchers to identify major cyber vulnerabilities.

About the author

ga_dahmani

Leave a Comment