Patch Management servers and Nessus

If you’ve followed the Nessus blog, you’re aware that Nessus, in addition to doing credentialed scans of a target can alternatively contact a patch management server (several are supported) and retrieve patch information for a target through the server that’s managing it.

Having talked to several people about this functionality, there’s been some confusion regarding it, so I thought a real world example might help:

Example 1

I have three hosts in my network:

  •  192.168.1.2 – WSUS Server
  • 192.168.1.3 – Windows 7 host being managed by 192.168.1.2
  • 192.168.1.4 – Windows 2008 host being managed by 192.168.1.2

When I create my scanning policy, I put in the credentials for the WSUS server (not the operating system, but the WSUS server itself), but don’t include operating system credentials for 192.168.1.3 and 192.168.1.4.

In my target range in my scan I put:

  • 192.168.1.2
  • 192.168.1.3
  • 192.168.1.4

When I run the scan, a network based scan is performed of all three targets.   It also discovers that 192.168.1.2 is running a WSUS server, so it puts in the credentials for there, and retrieves patch information for 192.168.1.3 and 192.168.1.4, since they are in my target range.

When I look at the results, it shows the missing patches on 192.168.1.3 and 192.168.1.4 even though I have not done a credentialed scan of those targets directly.  There Is also additional information in several plugins about the WSUS server itself.

Example 2

We have the same hosts as in example one.

When I create my scanning policy, I put in the credentials for the WSUS server (not the operating system, but the WSUS server itself), and I include operating system credentials for 192.168.1.3 and 192.168.1.4 in the credentials tab of the scan policy.

In my target range in my scan I put:

  • 192.168.1.2
  • 192.168.1.3
  • 192.168.1.4

Now, when I run the scan, a network based scan is performed on 192.168.1.2, and credentialed scans a performed on 192.168.1.3 and 192.168.1.4   It retrieves the missing patch information not from 192.168.1.2, but as a result of the credentialed scans.   There is also additional information in several plugins about the WSUS server itself.

Now, in a perfect world example 1 and example 2 would have an identical list of missing patches.   However, in the real world, patch management servers are not always accurate with respect to the hosts being scanned.   We can take the results of example 1 and example 2 and see if there are any missing patches in example 2 (the most accurate results) that are not in example 1.  We can also do the inverse, look and see if example 1 has any listed patches that appear to have been applied based upon information in example 2.

Source: Nessus and SecurityCenter