In this episode of Cyber Security Inside, hosts Tom Garrison and Camille Morhardt talk PSIRTs with Director for Red Hat Product Security, Pete Allor.
Pete has an impressive history with PSIRT and the convo covers things like:
• What a PSIRT is and why you need to have one
• The dangers of falling into a technical trap when addressing product vulnerabilities or problems
• Evaluating risk and scoring vulnerability
• Why incident response requires organization-wide coordination and communication
• The Incident Response Services framework
• The role transparency plays
• And more
Plus, Pete’s got a book recommendation, Camille’s got a tip for musicians forced to play in the dark, and Tom’s got a trivia question that will get you free drinks, every time. Check it out!
Here are some key take-aways:
• PSIRT is designed to address vulnerabilities with the company’s own products. If you don’t have a Product Security Incident Response Team, you need one.
• Get to know your auditor well and figure out what your risk tolerance is internally.
• PSIRT should be proactive, not reactive.
• We need to talk vulnerability scoring, so we have a commonality, a base to work from. And we need to talk about severity, as in risk.
• PSIRT is a coordinated effort. You need to give everyone the information they need, which means removing the technical babble and simplifying.
Some interesting quotes from today’s episode:
• “So fixing everything is not really the smartest thing because it's not necessarily a problem.
• “Now we're looking at ‘how do we respond?’ It's not just disclosing to us. It's a matter of publishing to our customers. But what we are publishing isn't a vulnerability. We're publishing a response. And that's the change in discussion we need to have.”
• “A customer can't do anything with the disclosure. They do everything with the response. And it's in our name: Incident Response. So we're giving them the tools to mitigate, we're giving the actions to mitigate, and we're giving them the code.”
• “I think we all fall into a technical trap sometimes, which is we focus on the issue itself. You know, this is broken. It's a TLS issue. It's a DNS mask. It's, it's something like that. And so we look at it from a very technical aspect. What we lose sight of is that it's an engineering response.”