A Wonk’s Guide to Effective Vulnerability Management

I’m going to cover something that arguably has the greatest impact on the security posture of an organization and is not something that information security is typically responsible for.

It’s something that can make or break a company’s entire security regime and negate every bit of security investment.

Poor security patch management.

A security patch is a piece of software designed to fix vulnerabilities or weaknesses in a system that could be exploited by malicious actors. By regularly applying security patches, organizations can protect their systems from being compromised and ensure that they remain secure and operational.

Traditionally, the information security team has processes for “vulnerability management” which is meant to discover, catalog, and track software vulnerabilities. Software vulnerabilities are weaknesses in code that can be exploited to gain unauthorized access or cause damage. While there are technical aspects to the vulnerability management process, the primary role is one of governance. The vulnerability management program is one of influence but does not directly fix vulnerabilities or patch systems. Therefore, the success of the program is primarily up to IT.

Knowing that the success of the vulnerability management program – and thus the entire information security program – is dependent on how well security patch management is executed, it is imperative that senior leadership prioritize security patching on par or above business imperatives. The “tone from the top” can either help achieve the desired security patching outcomes, or completely undermine them. For example, if a CISO reports to executive leadership that there are critical vulnerabilities that put the organization at risk and the response is short of “get it fixed ASAP,” then most likely nothing will be done – or will be done eventually, without urgency.

Even with executive buy-in, there needs to be a regular cadence of reporting that includes tracking not only raw numbers but also aging of vulnerabilities previously reported. Senior leadership then can set a “I don’t want to see this vulnerability again” tone for critical vulnerabilities.

The vulnerability report must be meaningful to the audience. Don’t waste their time with huge aggregate numbers. Instead, the reports should clearly articulate which vulnerabilities present risk to the organization and what patches would have the greatest impact in lowering risk. As the old saying goes, “if everything is critical, nothing is critical” so you need to choose what you communicate carefully.

However, these reports have a reputation for “naming and shaming” and only work for so long. Instead, the CISO needs to be partnering with the responsible leaders to help them succeed, and the quickest way to do that is to help them help you.

I am a huge fan of self-service, giving the IT operations team access to the vulnerability scanning system. It gives everyone the same set of facts to work from, security can partner when vulnerabilities are first detected and determine which patches should be prioritized. This not only speeds up the process of patching, it also buys quite a bit of political goodwill as the business unit leadership will be able to prioritize the patching effort. It also removes the CISO from the “gotcha” role they find themselves in when presenting reports to shocked leaders who will not have seen the information previously.

In addition, the CIO and CISO should partner on an effective system management product that can quickly and easily push out security patches. These tools are not cheap and require quite a bit of management to set up and maintain so it’s imperative that both IT and the security organization share both the costs and administrative burden of these tools.

Now for the other side of the partnership coin – accountability. The vulnerability reports must show aging critical vulnerabilities organized not only by platform type but also business unit. The only way to get traction in security patch management is to ensure there is complete leadership alignment and that if teams fall behind, there is accountability from the top which may include: timelines, follow-up, and visible consequences for continued non-compliance.

One last note, there is a temptation to treat vulnerability and patch reporting as simply an administrative security control and not a fundamental component of IT technical operations’ health. Unfortunately, this mentality may lead to critical vulnerabilities being handled with management exceptions or risk acceptance. As I’ve said to colleagues countless times, “attackers don’t check our risk register before launching their exploits.” Once again, tone from the top is imperative and leadership needs to understand that security patching is critical to the success of the health and safety of the IT ecosystem and cannot be documented away like other security risks.

I put the tl;dr version of this post here.

./dg