Reviewing Scan Results in Platform and Nessus

As a vendor agnostic platform, the platform supports and ingests vulnerability scan results from multiple vendors. As such, there are subtle differences between how a scanning vendor presents vulnerability scan results in their own console/management interface versus how those same scan results are presented in the Platform. This article focusses on those subtle differences between scan results from the Tenable Nessus Professional Console and the Platform.

Setup

For this article, the following setup was in place:

• The vulnerability scans were performed using Tenable Nessus Professional version is 10.3.0. A single scan was performed.

• The results from the completed scan were exported to a .nessus file using the export facility within the Nessus Console

• All issues from the .nessus file were imported into a single phase in the Platform in the usual manner (see this article for guidance on importing issues https://rootshellsecurity.atlassian.net/wiki/spaces/PK/pages/1304264726)

Reviewing Nessus Console

Introduction

Tenable Nessus reports scan results based on the vulnerability type (shown as the the vulnerability’s “name”) alongside the “Count” or number of times that a vulnerability has occurred.

This is an important distinction since the platform presents the same scan data differently, as we’ll discover later in this article

Nessus Console: Scan Summary

In the Nessus Console, we’ll take a look at the “Scan Summary” for our completed scan, paying attention to “Scan Details” and “Details” (highlight in blue below)

Open

The ‘Scan Details’ section breaks down the number vulnerabilities into of Critical, High, Medium and Low severity.

It is important to note that the numbers reported for each Severity under ‘Scan Details’ are derived from the instances, occurrences or number of times a vulnerability was detected by Nessus. In the above Scan Summary, 16 critical vulnerabilities were found. This means that Nessus detected 16 separate instances/occurrences of vulnerabilities; in this case, with a rating of Critical.

Nessus Console: Vulnerabilities

Open

Moving across to the “Vulnerabilities” tab, you can add up the number of critical vulnerability (types) and observe that the overall number of vulnerability types with a rating of Critical is 5. So there are 5 separate vulnerability (types) shown in the screenshot above.

For each vulnerability type listed, the “Count” column to the right hand side represents the instances, occurrences or number of times that each specific vulnerability type was detected by Nessus during the scan. For all critical vulnerabilities, if all the values in the “Count” column were summed up, the total would be 16 - a familiar number? The same value of 16 was reported under “Scan Summary” tab for Critical vulnerabilities.

Nessus Console: Vulnerability Detail

Lets drill into the first vulnerability in this list: Apache Log4j Unsupported Version Detection. This particular vulnerability was detected 11 times during the scan. That is to say there were 11 instances of this vulnerability discovered by Nessus during the scan

Along with vulnerability’s Description and Solution, the Output section shows in more detail where each instance/occurrence was detected by Nessus. In the context of this Log4j vulnerability and the method used by the plugin to detect it, Nessus lists the location for each offending log4j JAR file (highlighted in blue above)

On reviewing the vulnerability’s Output in Nessus, we can determine that:

• 2 hosts each had 3 instances of the vulnerability - 6 instances in total

• 1 further host had 2 instance of the vulnerability - 2 instances in total

• 3 further hosts each had 1 instance of the vulnerability - 3 instances in total

Summing up the host totals from above, we arrive at a total of 6 unique hosts that were affected by this vulnerability.

Summing up the instances totals from above, we arrive at an overall total of 11 instances of the vulnerability. Another familiar number? You may recall that under the main “Vulnerabilities” tab, the count for this vulnerability was given as 11 also.

Reviewing the Platform

Moving on now to the same scan results as presented in the platform, we have a single phase into which the scan results from Nessus were imported:

Under the phase, the “Issues Overview” and “Hosts Overview” tabs are reporting the same expected numbers - these match the scan results from Nessus:

Moving into the “Issues Overview” tab in the platform, you can observe the same quantity of issues, ordered by Severity (Critical first) in descending order.

For the same issue as reviewed in the Nessus Console (Apache Log4j Unsupported Version Detection), a keen eye will notice that the “Affected Instances” column reports a value of 6 and not 11, as may be expected when comparing to the same vulnerability from Nessus.

Whilst the platform will provide the same vulnerability information as found in Nessus (such as the Description, the Solution and the Output), the platform sums up the “Affected Instances” based on the number of unique Host & Port pairings. To illustrate this, we’ll drill into that vulnerability in the platform:

If you recall from the Nessus scan results, there were 6 unique hosts affected by the Log4j vulnerability - those same 6 hosts are now listed in the platform under the “Affected Instances” section (above)

In addition, you will recall from the Nessus scan results, the “Output” section presented detail on where Nessus found those offending Log4j JAR files. In the platform, that same information is given under the “Technical Details” section along with the specific host(s) on which they were found

Conclusion

To summarise the main points from this article:

• If you attempt a side-by-side comparison of Nessus Console results versus the platform, you’ll likely see differences in the “Count” (Nessus) and “Affected Instances” (Platform). This doesn’t mean the platform is ignoring or disregarding scan data, rather presenting the same vulnerability scan results in a consolidated manner (by Host/Port pairings and not by every single instance)

• The platform will report vulnerabilities based on affected Host & Port pairings. Whilst the “Technical Details” for an issue in the platform will still present all relevant output for a vulnerability, the platform will not consider the number of occurrences of a vulnerability on a single host if the Host/Port pairing is the same.

• Nessus will report all instances of a vulnerability, regardless of the affected host and port. This is what comprises the “Count” for a given vulnerability type (“name”) in the Nessus Console.

• To recap between the platform and Nessus,

  • In Nessus a vulnerability with a reported “Count” of 10 may comprise one host with 10 variations of the same vulnerability, or comprise 10 separate hosts each with one instance of the vulnerability, or any combination in between - the “Count” would still be 10.

  • In the platform, if 10 occurrences of the same vulnerability were found on the same Host/Port pairing, the platform would report an “Affected Instance” of 1. If the same vulnerability was found across 10 hosts, the “Affected Instances” would be 10