Last Updated: 24th July, 2022

Vulnerability Management: Whenever you think, regarding ‘Vulnerability Management‘ what would you think that means? Unless you’re one of the corporations, you might think about technology and tools for the first time apparently. The dialogue often goes hand in hand when we start asking clients about their vulnerability management program with the scanning tool that is already in use within their organization. That’s where most organizations get it wrong, regrettably.

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 with 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.

Vulnerability Management: 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.” In fact, just so many security groups ‘ mindset is “I only have to run the security screening application. 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 remediation 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?

Vulnerability Management: 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, huh? 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.

Vulnerability Management: Ad Hoc Patching – Define Your Maintenance Windows

One underestimated area of the 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 to buy in from senior management teams is so important. We need to negotiate reasonable maintenance periods with the business (to avoid business risk) to patch and reboot systems on a regular basis. Find out what works best for the appetite of your business risk.

There should be a constant exchange of information between security, IT and asset owners to ensure successful remediation.

Other than that makes 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 observed 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 regarding your business risk. The alternative is that you expose your company to risk – and, as a security person, you’ll get the blame when things go wrong.