May 28, 2020
All links and images for this episode can be found on CISO Series (https://cisoseries.com/defense-in-depth-bug-bounties/)
What is the successful formula for a bug bounty program? Should it be run internally, by a third party, or should you open it up to the public? Or, maybe a mixture of everything?
Check out this post for the basis for our conversation on this week’s episode which features me, David Spark (@dspark), producer of CISO Series, co-host Allan Alford (@allanalfordintx), and guest Justin Berman (@justinmberman), head of security, Dropbox.
Thanks to this week's podcast sponsor, Cmd.
Cmd provides a lightweight platform for hardening production Linux. Small and large companies alike use Cmd to address auditing gaps, implement controls that keep DevOps safe, and trigger alerts on hard-to-find threats. With out-of-the-box policies that make setup easy, Cmd is leading the way in native protection of critical systems.
On this episode of Defense in Depth, you’ll learn:
- Like red teaming, you need outside eyes looking at your environment and vulnerabilities.
- There was much debate between internal, private, and public bug bounty programs. But it was agreed that if you do them, that you do them in that order.
- There was another concern regarding the cost of a bug bounty program. Whether you do them or not, you're still going to pay for coding errors and vulnerabilities one way or another. It's either upfront or later.
- Those new to bug bounty programs are not aware of the additional costs of management and engaging with the researchers and white hat hackers. That is a critical part of the bug bounty program.
- Before you begin, set up a system to manage the flow of problems reported. If not, you and your staff could very quickly be overwhelmed.
- Having a consistent and clear way you handle the findings is often more important than the findings.
- Have you allocated budget to remediate the findings? Are you going to need to make cases as each weakness is found?
- Keep in mind that companies don't go into bug bounty programs for the same reason. Some go into it for reasons of publicity or forming relationships with researchers.
- Communications between your engineers and the bug bounty researchers is critical. If your team is non-responsive, the bug bounty program could backfire.
- Most people are wary of public bug bounty programs because of the low signal-to-noise ratio. As there is a rush for attention and money, the whole effort may implode.