One of the (Many) Challenges with SLAs in Vulnerability Management

In a recent discussion with a director-level colleague in an enterprise organization, we chatted about his difficulties in managing SLAs for over 500 different products within their organization. He faced a real challenge in balancing fixing vulnerabilities efficiently while accommodating varying vulnerability severity levels and workloads across different teams.  

The director said, “I have teams with 50 critical vulnerabilities and others with zero.” He wanted to create a vulnerability remediation policy to help guide all those teams. The first challenge he faced was picking an approach. Should they “fix all critical vulnerabilities within 30 days” and leave some teams without vulnerabilities to fix (in their ticketing system)? Should they “fix all critical + high vulnerabilities within 30 days” and then overwhelm other teams with critical and high vulnerabilities?  

This scenario got me thinking: there may be more effective solutions than the traditional approach of creating a blanket statement to address all critical vulnerabilities. When taken, the traditional route can lead to teams with zero critical vulnerabilities having no action to take while simultaneously overwhelming teams with multiple critical vulnerabilities. 

As an agile company, my colleague wanted to fix vulnerabilities in every sprint. To accomplish this, he had to explore alternative approaches to vulnerability remediation SLAs that would adapt to the maturity level of each team, which led to our discussion. Before we continue, let’s look at the background of vulnerability management SLAs. 

What are Vulnerability Management Service Level Agreements (SLAs)?  

Vulnerability Management SLAs are formal agreements that define the expected timeframes and standards for addressing and resolving software vulnerabilities within an organization’s IT infrastructure. These SLAs are typically set between the IT or cybersecurity department and the broader organization or sometimes with third-party service providers. 

The “Beauty” of SLAs 

The beauty of SLAs lies in their ability to provide a unified metric for measuring performance across different teams, irrespective of the varying standards to which each team is accountable.   

Let’s imagine a scenario where Team 1 has an SLA of 6 days to address critical vulnerabilities while Team 2 has a more lenient SLA of 14 days for similar tasks. SLAs abstract these differences, allowing for a straightforward measure of adherence, and measuring SLA adherence becomes a simple yet powerful tool for assessing whether an organization is functioning as intended.   

In this scenario, if both teams are meeting their respective SLAs, regardless of the different time frames, it indicates a well-functioning system tailored to each team’s unique capabilities and workloads. This approach avoids the pitfalls of a one-size-fits-all metric, offering a nuanced view of performance that respects the diversity of roles and challenges within the organization. 

Why Are SLAs Important in Vulnerability Management Processes? 

When implemented correctly, SLAs are a formidable tool. They provide clear insights into the health of an organization’s prioritization frameworks and remediation processes.   

Other SLA benefits include: 

• Standardization of Processes: SLAs provide a standardized approach to handling vulnerabilities. This standardization ensures consistency in the quality and effectiveness of remediation efforts across the organization. 
• Improved Security Response Time: SLAs establish clear timelines for addressing vulnerabilities, ensuring prompt action. This swift response is crucial in mitigating risks associated with vulnerabilities, reducing the window of opportunity for attackers to exploit them. 
• Enhanced Risk Management: By prioritizing vulnerabilities based on severity and potential impact, SLAs help organizations focus their resources on the most critical issues. This approach leads to a more effective management of risks. 
• Increased Accountability: SLAs define specific responsibilities for different teams or individuals involved in the vulnerability management process. This clarity in roles and expectations improves accountability, leading to more efficient and effective remediation efforts. 
• Better Resource Allocation: SLAs help organizations plan and allocate the necessary resources more effectively by outlining the expected timeframes and processes for vulnerability remediation. These resources can include staffing, tools, and budgets dedicated to cybersecurity efforts. 
• Compliance Assurance: Many industries have regulatory requirements related to vulnerability management processes. SLAs help ensure that vulnerability management practices comply with these regulations, reducing the risk of legal or regulatory penalties. 
• Performance Measurement and Improvement: SLAs enable organizations to track and measure the performance of their vulnerability management processes. Organizations can use this data to identify areas for improvement, driving continuous enhancements in security practices. 
• Enhanced Communication and Collaboration: The clear guidelines provided by SLAs can improve communication and collaboration from the board to individual remediators. 
• Proactive Security Posture: SLAs encourage a proactive approach to security that addresses vulnerabilities systematically before exploitation rather than reacting to security incidents after they occur 

Adapting SLAs to Team Maturity: Vulnerability Management Maturity Roadmap 

We must look to different spaces for inspiration to maintain progress as an industry. The earlier discussion with my director-level colleague and his agile enterprise inspired me to tap into agile principles.  

As builders of products, we emphasize adaptability and continuous improvement. Those same principles must be applied when creating SLAs for vulnerability remediation to ensure organizational efficiency and adaptability. 

Incorporating and considering vulnerability management maturity involves tailoring SLAs to meet each team’s needs and capabilities and dynamically prioritizing vulnerabilities based on severity, team capacity, and product criticality. It means thinking bigger than having just one blanket policy that applies to every team. How? You create an adaptable system that meets teams where they are and then shows progress per team while maintaining a single standard.   

Let’s talk through what this means.  

The roadmap below provides an example of leveraging this more adaptable and effective approach. Consider SLA adherence as a spectrum, not a single ‘yes’ or ‘no’ answer.   

For this example, let’s create a simple maturity scale representing all our steps to achieve the business outcome.   

1. Define the Business Outcome 

In this scenario, a business outcome could be a patch timeline from the date of discovery, such as a system including:   

• Emergency vulnerabilities are fixed within 48 hours  
• All critical vulnerabilities are fixed within 30 days, regardless of every other attribute.   
• All high vulnerabilities are fixed within 90 days  

So, how do we set up our system to support this outcome? 

2. Prioritize the Outcomes 

Let’s look at the options above and determine a priority for each outcome.  Is fixing emergency vulnerabilities within 48 hours the most important?  Or perhaps your normal critical vulnerabilities patch cycle is the most important? Write the outcomes on paper and number them in order of priority. You now have your levels of maturity for this SLA rollout. 

3. Document Maturity Levels 

The next step is to document your maturity levels.  You want every team to tackle getting these under control in that order. We’ll choose an order for this example. 

4. Develop Detailed SLAs 

For this step, I added more precision to the example SLAs to show you what a more realistic and advanced set of SLAs might look like, prioritized. 

Realistic SLAs might include:  

• All emergency vulnerabilities are fixed within 48 hours (with a clear definition of emergency vulnerability)  
• All critical severity vulnerabilities, remotely exploitable, being used actively in malware, and on a public-facing asset patched within 7 days  
• All high-severity vulnerabilities remotely exploitable being used actively in malware on a public-facing asset patched within 14 days  
• All critical severity vulnerabilities (in general) fixed within 30 days  
• All high severity vulnerabilities (in general) fixed within 90 days 

5. Visualize the SLA Maturity Roadmap 

Here’s a visualization of what that might look like for sharing with a team. Alternatively, you could create a matrix.