It’s perhaps no secret that vulnerability programs remain inefficient and ineffective. It’s why my most often requested client inquiries are about how to prioritize vulnerability remediation and improve patching. It’s clear based on my conversations with clients in those inquiries that vulnerability teams are overwhelmed with how to calculate the risk of vulnerabilities and misconfigurations while operations teams are frustrated with an increasing volume of unrealistic remediation and mitigation deadlines. There’s a growing disconnect between those two teams. How did we get to this point, and how can vulnerability teams regain the trust they once had?
Let’s look at a specific example to better understand how this disconnect has developed. In 2017, Spectre and Meltdown processor vulnerabilities consumed security teams for weeks. Researchers even developed those nifty marketing graphics that made them seem scarier than they really were. Five years later, there have been no reported known breaches due to these vulnerabilities. All three Common Vulnerabilities and Exposures (CVEs) comprising the vulnerabilities were issued a Common Vulnerability Scoring System (CVSS) score of 5.6 due to its difficulty to exploit. Mitigating chip vulnerabilities is very challenging, and when teams hurriedly implemented mitigations system, performance suffered drastically. This is a great example of how VRM teams have lost trust from other internal stakeholders. That trust must now be regained.
Enterprise environments are increasingly complex. Security and risk professionals have been forced to rely on CVSS scores for prioritization. These methods led to creating service-level agreements (SLAs) based on CVSS. Since CVSS was never intended to provide risk prioritization within each enterprise’s unique environment, this has led to goal misalignment. SLAs such as “Patch all critical CVSS scores within 30 days” do not weigh the business context of asset criticality, whether exploits are published and active for that vulnerability, and if there are compensating controls that can protect against that exploit. Vulnerability and operations pros also need to weigh the impact on customer and employee experience if systems go down for patching and rebooting, versus the likelihood (and more significant impact) of that system being down due to a realized exploit causing a breach.
In November, I’ll be presenting a session entitled “Reinvent Your Vulnerability Management Program To Regain Trust” at Forrester’s Security & Risk event in Washington, D.C. This talk will cover methods to prioritize vulnerability remediation and redefine service levels so we can extend the olive branch to operations teams that have grown increasingly skeptical of the VRM team’s ongoing flood of (often inaccurate) vulnerability predictions. I look forward to sharing with you all the strategies, controversies, and communication methods that are necessary to rebuild this trust.
Learn more about the Security & Risk event, and review the agenda here.
