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
