Introducing SLAs for Vulnerability Management

Apr 29, 2020
Lindsey Compton

Share with Your Network

Difficult tasks with arbitrary deadlines. 

If you work in cybersecurity, difficult tasks are nothing new. But they’re made unpleasant, and even impossible when the deadlines to complete them are pulled out of thin air or worse, “this is the way we’ve always set them” mentalities. 

Unfortunately, most of the service level agreements in the cybersecurity industry are, in fact, arbitrary. In vulnerability management, they’re based on 30-, 60-, or 90-day remediation timelines that have no reference in the real world. 

Here’s what we mean: in some organizations, there’s a goal to fix every vulnerability with a CVSS score above 7 within 30 days. Using this as an example, security teams assigning CVSS 7+ vulnerabilities would be asking their IT counterparts to patch nearly half of all known CVEs within a 30 day window. Hardly an achievable goal. 

But has anyone ever sat down and figured out if that’s a reasonable goal? Is the timeline too long? Too short? What are competitors doing? How fast can hackers turn this vulnerability into a weapon?

Kenna Security is answering those questions with Kenna.VM. It leverages 10 years of Kenna data to help companies set intelligent, data-driven SLAs based on the organization’s tolerance for risk, the criticality of the asset on which the SLA is set, and the risk of the vulnerabilities being addressed.  

These appetites for risk are divided into three categories. The first is for companies that are content to be as fast as their peers. The second is for companies that want to be leaders in their sector. The third is for organizations with the least tolerance for risk, companies that want their remediation strategies to exceed the speed of threat actors’ ability to weaponize vulnerabilities.

Based on these factors, Kenna.VM establishes suggested time-frames for remediation. In our research, the mean-time to remediation (MTTR) for all vulnerabilities on a corporate network is 180 days. Obviously, firms will want to shorten that time for high-risk vulnerabilities on critical assets. 

The typical organization, in fact, only has the capacity to remediate one out of every ten vulnerabilities, and in many organizations, internal debates over which vulnerabilities pose the greatest risk divert the attention of Security and IT teams away from the job of patching. Kenna’s incredibly comprehensive data set covers vulnerability exploits for the past ten years. It’s how we’ve been able to identify the 4 percent of vulnerabilities that pose an actual risk to an organization, and it’s how we help focus internal debates on ground-level truth. 

Evidence-based SLAs for vulnerability management is an idea whose time has come.

Kenna.VM is an ideal solution for mature cybersecurity teams that have relied on Kenna Security to guide their remediation strategies to an acceptable level of risk. By establishing data-driven SLAs, firms can devote an appropriate level of resources to maintain their ongoing vulnerability management risk tolerance, without sliding into old habits or reducing a sense of urgency on the part of the security team.

If you are interested in learning more about Kenna’s evidence-based SLAs, watch our on-demand webinar or sign up for a demo of Kenna.VM. 

Read the Latest Content

Research Reports

Prioritization to Prediction Volume 5: In Search of Assets at Risk

The fifth volume of the P2P series explores the vulnerability risk landscape by looking at how enterprises often view vulnerabilities.

5 Things Every CIO Should Know About Vulnerability Management

If you view vulnerability management (VM) as just a small part of your operation, it might be time to take another look.  Managing vulnerabilities is...



Get Started Using the Exploit Prediction Scoring System (EPSS).

Cyentia Institute’s Chief Data Scientist and Founder Jay Jacobs gives tips on how to get started using the Exploit Prediction Scoring System (EPSS). You...

© 2022 Kenna Security. All Rights Reserved. Privacy Policy.