False Positives in Nessus scans

It is a frequent occurrence for a vulnerability to be identified based upon the version string of a product or component alone. These kind of alerts often do not dissapear after remediation. Instead, a mitgation log has to be establised in order to manually track compliance.

By using version-only vulnerability plugins, it is mostly useful for deep scans while it is not as appropriate for frequent scans because it will only generate ‘noise’ consisting of false positives once the mitigation is deployed and a manual compliance process is established.

Advertisements

Using Nessus for software patch management

Today’s blog is about using Nessus for software patch management.

While Nessus is a popular tool for network security scanning, it also has some less obvious uses too, such as patch management, or more specifically, reporting.

Through allowing Nessus access to a device via an authorised system account, it can audit the package inventory on the device.

As Nessus supports many different operating systems and distributions, it becomes possible to manage your patch reporting for all of your device types (such as AIX, Solaris, Linux, Windows, Cisco IOS, MacOS X) from a single point of reference.

As all package vulnerabilities known to Nessus are scored like any other vulnerability, it is possible to categorise and qualify the patches in which you choose to apply.

This enables the patching policy to be driven by qualified security needs, and not “just because the vendor recommends it”.

Nessus can also plug-in to tools such as WSUS and Red Hat Satellite, however I am yet to explore what functionality it brings (i guess it will audit only against authorised patches or something…).

So by creating a ‘nessus’ account on the host (non-root/non-Administrator of course) in order to list the package inventory

Creating a ‘nessus’ account on the WSUS or Red Hat Satellite server

Configure a scan policy with local authentication and configure WSUS/Satellite with the required credentials

Select only local scan checks, exclude operating systems and scan type which do not apply to software package releases

Configuring a policy can be time consuming – don’t worry about de-selecting *ALL* of them – just get most of them – it’s only to speed up the scan anyway as those which don’t apply shouldn’t return a hit, so refine it over many iterations by removing more unwanted checks on second and third pass and so on.

Save the scan

Schedule a scan using that policy you just saved against your targets

…and viola! once the scan is complete – you have a single cross-platform patch report for all of your machines!