Jerry Perullo, former CISO of the NYSE, former chairman of the board off the FS-ISAC, founder, professor, and host of the Life After CISO podcast, comes down to the Cyber Ranch to discuss the many roles he’s had throughout his career and the many highly unique opinions he has on the cyber industry. Together, Jerry and Allan break down what’s overrated in cybersecurity, from patching to dark web to vulnerability departments, and every detail and concept in between.
[01:53] Taking on a variety of roles in the cyber industry and breaking down which elements of cybersecurity are overrated
[08:48] Recognizing when encryption is needed and when it is overrated or overemphasized as something you need in cybersecurity
[15:43] Service-level agreement timelines, addressing critical risks, and engaging with the 80/20 rule
[24:17] Understanding when to separate data about different vulnerabilities and attacks, and when to report on them in the same conversation (i.e. board meetings)
[29:58] Other overrated elements of cybersecurity, such as IoCs, dark web, and, of course, what Jerry would change in cyber if he had a magic wand...
Thank you to our sponsor Axonius for bringing this episode to life!
Manual asset inventory just doesn't cut it anymore. That's where Axonius comes in. Take control of security complexities by uncovering gaps in your organization. Sign up for a free walk through of the platform at Axonius.com/Get-A-Tour
Why is patching overrated?
While Jerry acknowledges the importance of patching in certain contexts, he also explains that it’s often overemphasized in its ability to provide cyber solutions. For patching to make an impact, the vulnerability has to be known and understood. In Jerry’s experience, patching doesn’t solve many of the problems in cybersecurity and can instead create a false sense of security, especially in the case of in-house coding errors. Although patching can create a long-term solution, you may only overcome that weakness for a moment and end up coming back to the same issue a few months later.
“When I say it's overrated is, first of all, patching is to address a known vulnerability in a piece of software, right? That means that the vulnerability has to already be out there, has to be profiled, has to be understood, and the manufacturer has to have actually created some kind of fix for it.”
What about encryption? Is that also overrated?
The idea of encryption comes from the idea of keeping information and vulnerabilities out of your enemies’ hands. However, too much focus on encryption blinds us to other issues and other tools that can be used against us. Although certain vulnerabilities around encryption are exploited, Jerry points out that you rarely, if ever, hear about the threats that we’re warned about when we’re sold on the concept and idea of encryption. With so many other ways to be hacked and exploited, Jerry says our focus on encryption keeps us in the dark about what the reality of online safety is.
“In any event, we spend so much time worrying about encryption and encrypting things, and whether it's encryption at rest, or whether it's in transit, or anything else like that, that I think sometimes we blind ourselves, especially on internal tools.”
Are short SLAs (service level agreements) for addressing critical risk overrated?
In Jerry’s mind, the timeframe of your SLA doesn’t matter if you need a problem fixed immediately. Whether it’s a 48 hour turnaround, a 29 day, or a 364 day window, critical threats need immediate fixes and your service team should understand that. If the response to a necessary and urgent request is for your team to inquire about the SLA, you have a much bigger problem than the time it will take. Instead you have a toxic culture problem, something that cannot be fixed with simple tweaks to your SLA.
“I always would just preach that you don't want to ever undermine your credibility. You don't want to bring weak sauce. Gotta be able to reproduce everything, have a video, all of that, and if you don't, then yeah, you people are gonna abuse your SLAs and push it to the edge.”
What’s your thoughts on departments with “vulnerability” in their name?
Although Jerry has had vulnerability departments and teams in previous companies he’s worked with, adding vulnerability to a department name rarely has the impact beyond specifying that they run the vulnerability scanners. Beyond running the scanners, processing these results and reporting them is a completely different beast. Rarely is a vulnerability department able to process and report these results without making data ten times more complicated and time consuming for your board to understand. They’re tool-focused, it’s in their name, but it may not be what you really need when you’re assessing risk.
“I think it's really important that you just speak about them all collectively, in a tool agnostic fashion. So, I feel the vuln scanner results, the bug bounty results, the attack service management results, the employees raising their hand and volunteering info…they need to be portrayed in parallel in one communication.”