We’ve said many times before that assessing performance in vulnerability management can be tough. This is because the number of vulnerabilities patched does not correlate with how well or badly your team performed. After all, in vulnerability management, the focus is not on patching as many vulnerabilities as you can; but rather on patching the correct vulnerabilities – those that pose the greatest threat to your business and have the greatest chance of being exploited – and quickly. Patch hundreds of small, unlikely vulnerabilities each day and it’s possible you’ve made little to no impact on your company’s security posture.
To get around the challenge of measuring performance, and to ensure that an IT security team is applying the maximum effort to the most appropriate activities, SLAs (or service level agreements) are set.
SLAs are contractual agreements between a service provider and its customer, or a business department and its stakeholders, that outline the terms of the services being provided, including performance standards and acceptable levels of risk.
There are different types of SLAs for different types of services. For example, an IT service company may have an SLA that guarantees a certain response time for fixing computer problems. A web hosting company may have an SLA that guarantees a certain percentage of uptime for its servers. In vulnerability management, the SLA is set to fix certain vulnerabilities within a certain time period, typically a number of days.
‍
SLAs are crucial in vulnerability management for a variety of reasons.
Firstly, they help ensure that vulnerabilities are addressed in a timely manner – one which is agreeable to both parties. Without an SLA in place, there is a risk that vulnerabilities will be patched too late or not at all and this can lead to a number of consequences, including:
Secondly, SLAs make sure that communication between the various parties involved is clear, and expectations are managed effectively. After all, if everyone knows what success looks like then it will be easier to strive for that goal.
Furthermore, SLAs can provide a valuable metric by which the performance of the vulnerability management process can be measured, and then improved upon over time. This benefits both parties: stakeholders seeking improvements to their service provided; and department heads looking for insight into individual team member performance or potential areas for automation or investment in the future.
Finally, SLAs can help build trust between an IT security team and its stakeholders, as they show that the team is committed to keeping its systems secure; not simply delivering for the first few months and then taking a foot off the gas from then on in.
‍
As we said before, in vulnerability management, the SLA is set to fix certain vulnerabilities within a defined time period. This may sound simple – set timeframes and then meet them – but there’s a lot more to it than that, as we’ll explain.
Typically when you set SLAs, you’ll go through a number of phases.
Phase 1 is to define the scope of the agreement - in the case of vulnerability management specifically, this would include areas such as: What types of vulnerabilities will be covered? Which systems or networks are included? Who is responsible for remediation? This is crucial in avoiding potentially disastrous gaps in coverage.
Phase 2, which we’ll come back to, is to set clear timelines and realistic goals.
Phase 3 is to define metrics and reporting requirements, i.e. if you need to report on your SLAs, how much detail should you give, how often and how much explanation is needed.
Then, once all of this has been set, phase 4 is to communicate the agreement to all parties involved and make sure it’s easily accessible should you need to check anything. This would be regularly reviewed and updated as the needs of the business change.
So now let’s delve deeper into phase 2 – setting appropriate timeframes.
‍
Google will give you various numbers of hours or days that you can set as your targets but we believe that there are a number of factors that need to be considered before you commit to timeframes for your SLAs. Taking careful consideration over these will help you to avoid failure while also giving you a strong case to defend targets which are lower than your stakeholders were hoping for.
‍
The process of setting SLAs effectively in vulnerability management starts with accurately assessing risk. This is because in order to set timeframes for remediation you need to correctly categorise the vulnerabilities in groups according to how high a risk they pose, i.e critical, high, medium and low.
You could use CVSS to do this but this is based on a technical view of risk; rather than how it will affect your company. What this means is that what they have scored as a 10, might be closer to a 4 for you. By grouping it in “critical”, rather than “medium” or “low” you’ll be diverting attention away from vulnerabilities that could have a greater impact on your business.
‍
A business can get as many as thousands of new vulnerabilities coming through in its scan data each time. That’s a lot to sort through, particularly if you’re doing it via manual triage.  According to our research, it can take a business as long as seven hours to sort through the vulnerabilities associated with just 250 assets. If you set certain time limits for remediating critical vulnerabilities but it takes you so long to sort through all of the scan data that you miss those targets, then you have a problem.
And it’s not just a question of time. Unless you have a consistent and repeatable process for classifying and prioritising your vulnerabilities, then you could end up with more vulnerabilities in the “critical” box than there should be, putting your remediation teams under unnecessary pressure.
This means when setting timeframes for remediation, you need to have an efficient, effective and consistent process for classifying your vulnerabilities – without it, your SLAs are doomed to fail from the start.
RankedRight can solve this problem. It will automatically prioritise all of our vulnerability data according to rules you’ve set based on your business risk appetite, ensuring that you waste no time in remediating what is most critical to your business. For more information on how RankedRight can help, book a demo.
‍
Burnout has hit the IT security industry hard. The pressure on teams to protect their businesses is growing so if you want to avoid a skills shortage, it’s important that you don’t add to the stress by setting unrealistic targets for remediation.
With the right vulnerability management platform in place to help you prioritise and delegate all vulnerabilities to the appropriate teams, thereby enabling them to take immediate action on the most critical risks, you will dramatically enhance their speed and effectiveness, but they will still have a limit.
Projects large and small can quickly become overwhelming if timelines are not well managed from the outset. As a steer, look for benchmarks or similar risks that have been resolved and use those as a reference point. Once you have a good idea of how long the task at hand will take, it is important to build in some flexibility. Things rarely go exactly according to plan, and leaving room for the occasional hiccup will help you to stay on schedule.
Following these tips will help ensure that your SLAs are effective and add value to the vulnerability management process. For more information on enhancing your vulnerability management efforts, contact us to learn about automation.
Peter is a skilled business operations and SaaS technology sales leader.
Curated list of articles to read next
