In this episode of Cyber Security Inside, hosts Tom Garrison and Camille Morhardt are doing things a little differently. Instead of bringing on a guest, they’re having a 1:1 conversation about the security side of product development and support.

They cover things like threat models, red teams, bug bounties, the role of PSIRT vs. PRT, no harm testing, SDL, issue mitigation, and more.

Check it out.

Here are some key take-aways:

  • When designing a product, you have to think about not just what you’re building your product to do, but also what it might be used to do.
  • Every time you learn about a new kind of attack or vulnerability, you want to bake those checks into your SDL process so you don’t repeat the same mistakes as a product is being designed. Automation can help, while also ensuring you don’t inadvertently open up an opportunity that you already learned about from a security standpoint.
  • If you only rely on external researchers to uncover vulnerabilities, you’ll leave yourself open to security threats and attacks.
  • It’s not good enough just to have a resolution. You have to make sure that the fix for an issue doesn't cause a problem somewhere else.
  • A challenge across the industry is figuring out how to communicate security fixes in a way that customers actually care about.
  • You have to think holistically about your product and you have to think through the security implications — all the way from when you’re initially designing a product to when it’s out in the wild and customers are actually using it. And it takes real investment along the way to do that.

Some interesting quotes from today’s episode:

“Prior to release, we want to go and attack that and see if we can find something ourselves or through a partnership with somebody who's going to let us know what it is. So we've got time to fix it before it actually goes live. And that's a real investment.”

“I think more companies are now becoming aware that this is not something that you can just rely on external researchers to do the work for you.”

“First thing is we have to figure out, is it really a problem? A lot of times researchers just make mistakes or they trip onto an already known vulnerability. And so what we need to do is figure out, is this new? Is it actually an issue or not?”

“You've got to make sure that those learnings that you had internally get recycled back into that Secure Development Lifecycle, so that people who are starting new products are now aware of this new discovery that you've made and are incorporating those learnings into the build.”

When the hole gets filled by the industry, then the attackers go find the next hole. And our job, by the way, within the industry, is that we want to be actually ahead of the attackers.”

“Security is one of those topics. It's very intimidating for people, especially people that aren't deep in security. And so as a feature, what ends up happening is it sort of gets lumped in with just a bunch of other stuff in a product that people don't really understand.”

“Where we are embarking as an industry is to point out that not every company does security, even the basics of ‘how do they support their products?’ There's no real unanimity across the industry in terms of how to do that. And those are things that customers really care about.”