Knowing When to Patch

I was on an enterprise vulnerability management panel at the recent Infosecurity show in NY City. On the topic of patch management, a question was asked about using severity ratings for vulnerabilities to select which patches to apply, or the prioritization of which patches to apply first. This blog entry captures my comments from the panel and my general thoughts on the subject.

Don't Let Your Vulnerability Scanner or Penetration Tool dictate your patch policy!

I'm running into more and more people who use Nessus or a penetration testing tool like MetaSploit to discover the "serious" vulnerabilities on their network with the intent to just patch those. This can fail for several reasons.

First, consider three Microsoft Exchange servers, all equally configured except you have credentials for one, the other is behind an IPS and you can only scan the third one. Your vulnerability scanner will likely give you different results for each server, even though they are configured the same.

Second, as far as scanners go, your penetration tool, vulnerability scanner or patch auditing system aren't all built the same way. They may indeed be able to test for vulnerabilities only one way. At Tenable, we often try to make sure we can perform both a remote network check for Nessus, but also try to back it up with a host based check. We extend this even further trying to be able to "sniff" the vulnerability with our PVS. The point is though, that scanner to scanner, you may have different detection algorithms.

And third, even if you have accurate detection, your scanner vendor may set different severity levels for the vulnerability. At Tenable, we include a risk factor, a CVSS score and a severity level for most vulnerabilities detected by Nessus or the PVS. What we score something at may be very accurate or not for your organization. More than 100,000 organizations trust us to write Nessus checks for them, but I would not argue that they should make patching decisions solely based on what Tenable's research group says.

So unless you are very careful about what you are scanning, using solely the results from your scanner can lead you to inconsistent patch levels on the systems you are trying to secure. This can make applying future patches more difficult since there may be different patch levels or dependencies.

Patching Polices That Scale

If you are part of an organization that is always patching based on the latest threat, you will be expending many cycles always being reactive. Instead, it is much better to align patching process with business processes.

Consider those Exchange servers I was mentioning before. I would consider a mature IT organization to manage those servers exactly the same, with a consistent patching policy. Such a policy would include a timeline to test patches and to install them.

It would also include guidance for what sort of patches to install. This could include the use of 3rd party patches. It could also recognize that a patch for "Google Desktop" is indeed available, but that application isn't authorized to run on that system.

The point is that we shouldn't be surprised by new vulnerabilities and leap into action to test how vulnerable our network is to them. This will only lead us into more and more random configurations of our network. Instead, setting patching policies which make sense for each key asset allows for more scalability and consistency than simply applying patches because they are available.

Working with Network and Patch Management Systems

I've blogged last month on some reasons why patch management can fail. In the context of this blog entry, I'd like folks to walk away with the idea that their vulnerability discovery process should be part of their change control and network management process:

• Systems with vulnerabilities should be evaluated to see if they are being "managed". This means that the system is actively being patched and has a configuration consistent with IT policy.
• All "managed" systems should be evaluated to see if the service level agreements (SLAs) for applying patches are indeed being met. This means that the vulnerabilities you do find should only be "new" ones or ones the organization has chosen to accept the risk for.
• Vulnerability detection (both passive and active) can be used to look for both authorized and un-authorized changes, which may have impact on network management and compliance

Where Tenable Can Help

Nessus and the PVS can obviously be used to discover vulnerabilities, but for independent auditing of the network as a business, the Security Center can be used to help answer many of the questions raised here including:

• detection of vulnerabilities by unique asset type (i.e. a corporate laptop vs. the Exchange server)
• mis-configuration issues for specific asset classes (i.e. all corporate laptops need to have "AutoRun" disabled for CDs and USB drives)
• tracking the life-cycle of vulnerabilities and patches by unique business groups and corporate assets
• communicating clear mitigation tasks with IT about configuration changes, corporate patching policy and their specific vulnerabilities

If you'd like more information about the Security Center, please feel free to contact Tenable's sales team.