Stop using your vulnerability scanner for patch auditing!

Patch auditing is important, and you should do it, but your vulnerability scanner or sevice can (and should) do so much more.

Patching is designed to address the things you know about (or should know about). What about the things you haven't considered?

At first, this sounds counter-intuitive, but consider the goal for doing a vulnerability scan: to identify unaddressed weaknesses. If you have a patch management program, you already know about patches. If it has gaps, you need to know that, of course. But, what about security baselines? If you focus on auditing your patch management to the exclusion of all else (the noisiest aspect of vulnerability assessment), you run the risk of exposure due to misconfigurations that can be far worse than the patches you've missed.



I think the flaw is introduced when most organizations acquire their first vulnerability scan or scanner. As missing patches have been the focus of security awareness efforts for so long (and with MS08-067 still being found missing, it's certainly warranted), organizations are tempted to focus on this aspect of their scan results. I've seen vulnerability scanners become little more than patch auditing solutions for WSUS or SCCM.

Some might go so far as noting that third party products are not being patched, and direct program focus towards that. But, in the end, operational outfits end up with a grocery list of CVEs that may or may not be linked to vendor alerts that can be easily fed into the normal patching program, and operations gets overwhelmed by the scope of the effort.

Instead of issuing a fix ticket for every missing patch and attempting to determine a priority for all of them, identify the gap or weakness in the overall patch management program and let the owners of that system or process address the differences. It's seldom about which patch is missing. Usually, it's more significant that there are systems or applications that are not being patched at all, or that the patch management system is failing in some significant way. Why overwhelm administrators with exhaustive lists of every patch? Patch management programs and mechanisms should come with validation processes capable of operating independently of a vulnerability scanner. The absence of this mechanism is a statement about the patch management process itself, and should be addressed accordingly. Binding your vulnerability analysts in the political struggle about individual patch prioritization is a mistake.

Similarly, despite the efforts of CIS, secure benchmarks are often so comprehensive and limiting, and designed to counter every possible scenario of compromise, that security configuration management has become a grocery list for remediation. Information security groups are left, arms full, holding the bag for prioritization of effort. And, they often don't have much more to go on than some casually worded advice that has no proof of concept for testing. Determining livable secure baselines is, ultimately, a collaborative effort between operational areas and Information Security. And the value-add of a good InfoSec department is being able to negotiate through the fear, uncertainty, and doubt, while listening to valid concerns about interoperability impacts of secure configurations.

But, once those benchmarks and baselines are established, InfoSec departments, once more, have to avoid being bound up in prioritizing remediation for the grocery list of findings. Once baselines are established and implemented, gaps indicate problems in baseline management, change management processes, and inventory control. The information you get from a vulnerability scanner will be most valuable in identifying those gaps so that they, too, can be addressed by the operational areas that own those processes. Focus on the gaps instead of the individual grocery list items.