When you think about ‘vulnerability management', what comes to mind? If you’re like most companies, your first thought might be about technology and tools. When we ask clients about their vulnerability management program, the discussion often starts and ends with the scanning tool that’s in place within their organization. Unfortunately, that’s where most organizations get it wrong.
A successful vulnerability management program is all about the reduction of business risk — and not just about having the best vulnerability management tool in place. The tools involved are obviously key, but they’re a part of the overall picture.
Throughout my years of experience dealing with organizations on vulnerability management, I’ve found hundreds of ways organizations set their program up for failure. Here are just three of those mistakes, and how to fix them.
A lack of structure — define goals, policies and ownership
Far too many vulnerability management programs fail because there’s nothing supporting them beyond the notion that it’s “just something we need to do”. Moreover, the attitude of too many security teams is “I just need to run the security scanning tool. Whatever happens after that isn’t my problem.” So the idea of a cohesive team goes out the window.
The first step to fixing these problems is to set goals, clear ownership and policies. Why? Because you do not want a position where the security team is blaming the IT team for not remediating vulnerabilities, and the IT team is blaming the security team for poor data. After all, if you don’t set any rules, you can’t hold anybody accountable for any failures.
So look to answer the following questions: What do you want to achieve with your program? How does each team define success? What does each team need to be successful? How do teams ensure that other teams are successful within the program?
Overloaded IT teams — prioritize the most important vulnerabilities
When it comes to operations, vulnerability management should follow a set process:
In my experience though, I’ve come across many clients that go straight from the discovery phase to the remediation phase, skipping out the prioritization of assets, assessment and reporting stages in between.
This often happens when organizations don’t scope their programs very well. They treat every asset, every network, every device the same, so in some cases, the organization ends up under-scanning or over-scanning, and nobody assesses the quality of the data that comes out of the tool. The end result here is that the same vulnerabilities crop up month after month because the remediation teams are either overloaded with a spreadsheet full of thousands of rows of data or they don’t know which information is accurate and what to prioritize among a million other weekly tasks. It’s the ultimate failure loop.
So what to do about it? The first is to properly scope your scanning. Make sure you know which of your assets need weekly scans, which need monthly scans, and allow for resources to analyze the data before any remediation work takes place. That way, you can make sure that you only flag the most important vulnerabilities to your IT teams, enabling them to prioritize patching more efficiently.
Ad hoc patching — define your maintenance windows
One underestimated area of point of failure is the lack of defined maintenance windows, which can absolutely kill remediation teams. If you’re running ad hoc maintenance windows to patch servers, you’re setting yourself up for failure.
This is where getting buy in from senior management teams is so important. We need to negotiate reasonable maintenance periods with the business to patch and reboot systems on a regular basis. Find out what works best for the risk appetite of your business. There should be a constant exchange of information between security, IT and asset owners to ensure successful remediation.
Other than that, make sure you’ve got a robust patching platform and have the resources available to manage the platform. Don’t have part-time resources — you need a team that’s confident in how the platform operates.
Also, it’s not uncommon for security and IT teams to disagree on the severity of a particular patch. When this happens, a senior leader needs to be prepared to make the final decision. I’ve seen too many times in meetings people just looking around for someone to step up and make the call. Either people think it’s everybody’s decision or they think it’s nobody’s decision. Choose one person to make the final call.
Hopefully by now you’ve realized that vulnerability management isn’t just something you can just “do”. It requires proper planning and real resources to make it work, and I’ve only just scratched the surface in terms of the kinds of mistakes most organizations make.
In this article, I’ve covered at a very high level some of the issues with governance, operations, scope definition, prioritization and remediation, but I come across hundreds more issues with areas like asset management, scanning, change management, verification and reporting.
Part of the problem is simply being able to explain to the business how important vulnerability management is — so leadership teams sit up and take notice. It’s not an easy conversation to have when business execs have a thousand other priorities but seek out an expert to help you have those discussions with your business.
The alternative is that you expose your company to risk — and, as a security person, you’ll get the blame when things go wrong.