False positives management

Commonly, false positives in vulnerability scanning occur when the scanner can access only a subset of the required information, which prevents it from accurately determining whether a vulnerability exists.

To help reduce the number of false positives, you must configure your scanners with the appropriate credentials. The scans need access to all of the asset information required information from assets so that you can accurately determine whether a vulnerability exists.

Why do false positives occur?

A false positive might occur when the scanner can read only the configuration information from service banners. For example, a scanner that reads an Apache banner can detect that only version 2.2.15 is installed from the HTTP banner, even when version 2.2.15-39 is also installed and that the version contains a software fix that was backported.

Another example is when the scanner reads the banner and detects the version of SSH that is installed, but can't detect the patch level or the operating system. If the scanner detects that SSH-2 is installed but can't determine the operating system, the scanner can't accurately determine whether a vulnerability exists in some instances. The vulnerability might be correctly identified on one asset but is a false positive on the other asset because SSH vulnerabilities on Red Hat SSH might not be the same for other Linux® operating systems.

Why don't scanners retrieve all the required information

Vulnerability scanners can't always access the information that they need to accurately determine whether a vulnerability exists. This limitation commonly results in false positives.
Scanner can't authenticate

If the scanner can't authenticate on the end point, the scanner must rely on the limited information from anonymous network services probing such as the information retrieved from reading banners.

Banners might contain incorrect versions and outdated patch-level information, which results in false positives. However, if the scanner can authenticate, it can determine the full version of the operation system and patch-level information, and then suppress any false-positive vulnerabilities.

Best practices about banners

Use these best practices about banners when you set up vulnerability scanning in your network:

  • Don't include detailed or sensitive information in a banner because a hacker can get crucial information about the applications and services that are running on an asset and then use known vulnerabilities to exploit them.
  • Know the type of information that is available anonymously in banners. Assess the likely attempted attack vectors. This information is helpful for assessing your network security, and for gathering network information.
  • Flag vulnerability information that is read from banners as false positives by tagging the vulnerability as an exception from tabs such as the Vulnerability Instances pane of the Asset Details window or the Vulnerability History window.
  • Tune scans by enabling or disabling tools in scan policies that can prevent these scans from starting.

Authenticated Windows based scan techniques

Authenticated Windows based scanning uses the following two techniques to detect vulnerabilities:

  • Registry scanning where the scanner needs access to the registry.
  • OVAL scanning where WMI (Windows Management Instrumentation) must be configured correctly.

If either of these two techniques fail, then the scan result is prone to false positives.

You must enable the remote registry service for the scanner to access the registry.

Misconfiguration of WMI (Windows Management Instrumentation) can generate false positives.

Identify authentication failures

If a scan does not authenticate successfully, hover your cursor over the warning symbol see why the scan encountered issues. For example, 
The last scan of this asset failed 
STATUS_LOGON_FAILURE 
Therefore the vulnerability may not be accurate
Other examples of warnings messages include, SSH logon failure, remote registry service not started, and no WMI access.