Kimber Dowsett on developing and maturing a vulnerability disclosure program

O'Reilly Security Podcast - O'Reilly Media Podcast

The O’Reilly Security Podcast: Key preparation before implementing a vulnerability disclosure policy, the crucial role of setting scope, and the benefits of collaborative relationships.

In this episode, I talk with Kimber Dowsett, security architect at 18F. We discuss how to prepare your organization for a vulnerability disclosure policy, the benefits of starting small, and how to apply lessons learned to build better defenses.

Here are some highlights:

Gauging readiness for a vulnerability policy or a bug bounty program

It’s critical to develop a response and remediation plan before you launch a disclosure policy. You should be asking, ‘Are we set up to respond to vulnerabilities as they come in?’ and ‘Do we have workflow in place for remediation?’ Organizations need to be sure they're not relying on a vulnerability disclosure policy to find bugs, vulnerabilities, or holes in their applications and code. It’s critical to ensure you have a mature, solid product in place before you open it up to the world and invite scrutiny. Additionally, vulnerability disclosure policies and bug bounty programs shouldn't be thought of as low-cost quality assurance. Code that hasn't been tested isn't viable for these programs. If your product hasn't been tested, torn apart, tested again, gone through pen tests, then it’s not ready, particularly for a bug bounty program. Even if you're ready for a vulnerability disclosure policy, there's a good chance you're not yet ready for a bug bounty program.

Start small and proceed with caution

If you don’t start small, there's a good chance you're going to get hit in ways that you're not prepared to handle, and probably with issues you'd never even considered. When we launched the 18F policy, we launched it with three sites and then rolled out additional sites as they were ready. If a team said to me, ‘Okay, we think we're good to go to be added to the disclosure policy,’ then we would review their pen test results, development, back end, and code reviews. It's a much slower process, but it returns better results. Going all in at the start and declaring that everything is in scope for your policy is shooting yourself in the foot. We have been cautious and we've had a very successful, slow rollout of vulnerability disclosure. We've proceeded with caution and that worked well for us.

The benefits of building collaborative relationships

When we confirm a vulnerability, our blue team explores how we would defended against it or ways we could defend it until remediation is complete. Then, our pen testers, security engineers, or developers look to add something about the vulnerability to their toolkits to test for similar insecurities as they are building apps. We really shoot for baked-in security, but there's always going to be a ‘gotcha.’ If researchers submit reports in meaningful ways, we are able to use that to save ourselves time and energy with the triage process, and move straight to determining the best defense and how to find and secure similar problems in the future. We’ve built a process that fosters collaborative relationships with researchers. When researchers make high-quality submissions, we ensure their discoveries are welcomed, and of course, responsibly disclosed. In a successful program, researchers have become part of the security process, as they’ve contributed in a meaningful way to the security of one of our applications. When researchers feel welcome, we all win.