Nothing brings excitement to a room like discussing Service Level Agreements (SLAs), but they are extremely critical to keeping your business in line with your obligations. You may also require your vendors to provide you with an SLA. If you have a requirement to manage your vulnerabilities within a certain time window, or you require your vendors to do so, this article is for you. In this first section of the guide, we’ll lay out the potential considerations for structuring a vulnerability management SLA. In the second part, we’ll get into how to implement a vulnerability management SLA and how HostedScan can be applied to help successfully run your policy.
What are SLAs and how do they apply to vulnerability management?
Before jumping into the vulnerability management side of SLAs, let’s lay the groundwork for understanding the structure of an SLA. An SLA is a legal document signed between you and your customer if you’re providing a service or software, or between you and a vendor if you are the purchaser. If you are an MSP or MSSP, you’re signing SLAs with your clients. If you’re purchasing software, you likely have your vendors sign an SLA with you.
Generally, the SLA describes the level of service the vendor is obligated to provide the purchaser along with the remedy consequences if that obligation is not met. Consequences for missing an SLA are often financial and can become expensive for the servicer if they fail to meet their level of service. For SLAs, the level of service is a broad topic, but it frequently encapsulates:
Uptime/Availability: The percentage of time a service is operational. Common SLA targets are 99.9% ("three nines") or 99.99% ("four nines") uptime. This is frequently seen with Saas software, and cloud providers like AWS, Microsoft Azure, Google, etc. Here is theAWS Service Level Agreement for Monthly Uptime as an example:
AWS Uptime SLA
You can see that in the case of AWS, outages of more than 5% give service credits of 100%, that is AWS takes a total loss for the month. A very expensive consequence, but outages impacting their customers for 5% of the month may mean millions to billions in impacted revenue, and a more difficult to judge hit to the customer’s reputation.
Vulnerability Remediation Time: This is the time taken to resolve a vulnerability based upon the vulnerability's severity or other possible categorizations. A vulnerability remediation SLA would have a table, outlining each severity and expected timeline for resolution. Typically, this would state that critical vulnerabilities must be resolved in 24 hours to a few days, and high vulnerabilities in a few days to weeks, etc. The timescales here are quick examples, but may vary widely based on the agreement and vendor.
Vulnerability remediation SLAs are critical to ensuring the confidentiality of data. A critical, zero-day vulnerability may be in active exploitation as soon as it’s discovered. We’ll be focusing on vulnerability remediation SLAs for the remainder of this article and the second part of the guide.
Incident Response Time: The time taken to respond to a security incident. Typically, this may be within a few hours to a day. Hopefully, fast as a security incident can ultimately have
Other items in an SLA may include: Data Backup Frequency, Disaster Recovery Time, Customer Support Response Time, System Maintenance Windows and Change Management Notifications. We’re going to focus primarily on vulnerability management and remediation as it relates to SLAs in the remainder of this article.
How should I categorize and prioritize Vulnerabilities in an SLA?
Vulnerability SLAs define how quickly a vulnerability must be fixed. Vulnerabilities are often prioritized around severity. Typically, vulnerabilities are ranked as critical, high, medium, low, or informational based on their assessed impact. In the case of Common Vulnerability Exposure (CVE), CVEs are scored using the Common Vulnerability Scoring System or CVSS for short. The CVSS score ranges from 0 to 10, with 10 being the highest severity and 0 being the lowest severity.
The CVSS scoring creates categories of severity based on the score assigned to the vulnerability.
CVSS Score Severity Breakdown
This is the most common categorization used in SLAs to determine how quickly a vulnerability must be fixed. Agreements will specify a specific time window for each of these severity levels ranging from a few days, to weeks, or even months.
While vulnerability severity is often used as the criteria in deciding how quickly a fix must be made, it may be too coarse a category or misaligned with the specific concern at hand. Other potential categories include:
Exploitability: This distinguishes between vulnerabilities that are exploitable and those that are theoretical with no known practical exploits. A popular score for this metric is the Exploit Prediction Scoring System (EPSS), which estimates the likelihood that a particular software vulnerability will be exploited in the wild. A medium severity vulnerability might not seem particularly important, but if it is being frequently exploited in the wild, it would be reasonable to place a higher priority on it.
Nature or Type: Categorizes vulnerabilities into technical, configuration weaknesses, design flaws, or physical vulnerabilities. You may see this categorization more frequently in compliance based SLAs. HIPAA or PCI for example, specifies policy controls one must have in place based on the nature or type of vulnerability. An extreme example of why you may want to incorporate the type of vulnerability: fixing a high severity vulnerability in software, doesn’t matter if the server is left out on a shelf of an unlocked room for someone to grab. That’s why prioritizing physical vulnerabilities may be more important.
Impact: This focuses on whether the vulnerability affects confidentiality, integrity, or availability of the vulnerable system. A high severity vulnerability may affect the availability of a system, but not threaten the confidentiality of the data in the system. In this case, it may make sense to rank the vulnerabilities based upon critical need: does data confidentiality out rank availability?
The correct choice for you is based on your business requirements, and those of your customers or vendors. By far the most common choice is to choose a set of time tables based on severity, but while this may meet specific compliance requirements, it may miss the mark on actually securing the relevant systems.
Vulnerability SLA challenges
On the face of it, a vulnerability SLA may seem simple. But there are a couple of big challenges that come up when putting one together and implementing it:
- How are vulnerabilities discovered and prioritized? The specifics are often left out of an agreement and may greatly impact how well an organization keeps up on their obligations.
- While severity is often used, it’s not necessarily the right fit for all business cases. Severity misses out on the exploitability of the vulnerability, the type of vulnerability, and it's nature as seen above.
- A big concern is tracking remediation times to ensure they are being met according to the vulnerability remediation SLA. You can imagine having tens to hundreds of vulnerabilities for a single project, each of which falls into a specific requirement of the SLA, and requires attention on a specific timescale. Start scaling that by adding more projects, more teams, and more agreements, and the scope of the challenge becomes daunting.
In the upcoming second part of this article, I'll discuss how to create a vulnerability Management SLA, and how to meet these concerns head on. I'll also discuss how HostedScan can help with your SLA.