Risk-based SLAs 101

Sep 15, 2020
Monica White
VP of Product Marketing

Share with Your Network

Earlier this year, my colleague Lindsey Compton, introduced the concept of risk-based service-level agreements (SLAs)—a new addition to Kenna.VM, our flagship risk-based vulnerability management solution. This is a first for our industry, so we’ve been engaging with customers and prospects on this new feature, answering any and all questions that pop up as folks get accustomed to this game-changing approach. 

Defining your SLAs with risk-based variables

In Kenna.VM, risk-based SLAs provide remediation timeframes based on your company’s tolerance for risk. The central idea is the lower your risk tolerance, the faster you’ll have to remediate. Our risk-based SLAs are dependent upon three key factors: the risk tolerance of the client, the asset priority upon which the SLA is being set, and the vulnerability risk score (high, medium, or low). So, there are different risk-based variables at work here that inform your SLA. 

Sounds a bit complicated, but is it worth it? Yes, we believe it is. And the good news is, we take care of the complicated pieces for you. All you have to do is define your risk tolerance.

How modern vulnerability management informs risk-based SLAs 

Kenna’s Chief Product Officer, Jason Rolleston, recently wrote a blog series on the journey that companies go through when they adopt a modern vulnerability management (MVM) approach—when they begin to truly operationalize risk-based vulnerability management. In the early stages, organizations work consistently to reduce their risk score. But the law of diminishing returns changes the nature of the game as organizations mature in MVM. 

The root of risk-based vulnerability management has always been to focus on remediating the vulnerabilities that pose a real risk first to your specific organization and at Kenna, we don’t believe you should remediate everything because not everything is worth remediating. This deviates sharply from the traditional “everything is at risk” mindset. 

The law of diminishing returns suggests that when you increase one input while all other inputs are held steady, you’ll reach a point where you progressively yield smaller outputs (see the graph below). 

At Kenna, we believe this principle applies to MVM; at some point, the time, effort, and resources you’ll be putting into reducing your risk score won’t be worth the remediation of that vulnerability (because it didn’t pose a real enough risk to begin with). As an organization reaches a more mature MVM state, its risk score would enter a steady-state wherein Security and IT should seek to maintain it, rather than reduce it (visualized in the graph below).  

What risk-based SLAs can do for you and your team 

Reducing your risk score will eventually become a less and less effective means of measuring your team’s performance. Your risk score will periodically spike as vulnerabilities arise or change in severity. At that point, the ability to remediate quickly and maintain your acceptable risk score threshold becomes the priority. This is where risk-based SLAs offer significant advantages. 

Risk-based SLAs give meaningful, data-driven recommendations for remediation timelines based on your organization’s appetite for risk, rather than the standard arbitrary 30-/60-/90- day SLAs. This means that you can: 1) base conversations between IT and Security on defensible, evidence-based timelines, 2) optimize resource allocation for remediation, and 3) fine-tune and increase your risk remediation response to maintain your risk score. After an organization reaches an acceptable risk score, SLA adherence becomes a much more effective measurement of performance than risk score reduction. 

The data behind risk-based SLAs

If we’re recommending SLA timeframes (which depending on your appetite for risk, may be quite aggressive), it’s natural to want to understand how we’re getting to those numbers. To do this, it’s helpful to understand the two buckets of data that underlie Kenna.VM’s risk-based SLAs: Mean Time to Remediation (MTTR) and Median Time to Exploitation (MTTE). 

MTTR signals how fast organizations using Kenna.VM are remediating vulnerabilities. For an organization with a high risk tolerance, a recommendation of “50 days” means your peers are remediating a vulnerability within an average of 50 days. Kenna’s robust collection of MTTR data feeds into the recommended SLA timeframes for organizations that have either a high or medium risk tolerance. 

For organizations with a low risk tolerance, we leverage MTTE data to calculate SLA time frames. Using our vast database of threat and exploit intelligence, Kenna can identify how fast attackers are exploiting vulnerabilities. When Kenna.VM recommends that you remediate a vulnerability within two days, it means that attackers will exploit that vulnerability, on median, within two days. Again, some of these timeframes can initially seem aggressive. But keep in mind that there is only a small subset of vulnerabilities for which we will recommend a short timeframe. For the overwhelming majority of vulnerabilities, you will have more time—and likely, more time than you thought. And that’s ultimately the Kenna value: We help you focus your resources on the small quantities of vulnerabilities that truly matter, freeing up time, money, and resources to dedicate to other strategic initiatives.

Learn more about risk-based SLAs 

Check out our on-demand webinar, “The Road to Launching Risk-Based SLAs,” in which Jason chats with Michael Roytman, our Chief Data Scientist, about the inner-workings of this new capability and how businesses looking to build a modern, risk-based vulnerability management program can benefit from it

The Road to Launching Risk-Based SLAs

Watch this on demand webinar and get a walkthrough on how more targeted, achievable SLAs require extensive peer benchmark data, real-world threat intel to identify likely exploits, data on the speed of attackers, and an understanding of your risk tolerance

Watch Now

Read the Latest Content

Vulnerability Management

Vulnerability Management Maturity Part One: Growing Pains

The first of a three-part series on the three stages of vulnerability management maturity. In many ways, it's built from a lot of hard work and experience.
Vulnerability Management

Vulnerability Management Maturity Part Two: Training Day

The second of a four-part series on the stages of vulnerability management maturity. Now we're training in the ways of risk-based vulnerability management.
Vulnerability Management

Modern Vulnerability Management Part 3: Engaging Auto-Pilot

Modern vulnerability management isn’t just about making life easier for the security team. It is about reducing the amount of time that IT spends patching.

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