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.