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.