Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As a vendor agnostic platform, Prism 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 Prism Platform. This article focusses on those subtle differences between scan results from the Tenable Nessus Professional Console and the Prism 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.

  • In the Nessus Console, the CVSS Base Score for this vulnerability scan was changed to CVSS version 2. Prism rates issues based on a vulnerability’s CVSS v2 score.

  • 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 Prism Platform in the usual manner (see this article for guidance on importing issues Importing Third Party Results (Issues))

Note

IMPORTANT NOTE: The Prism Platform rates imported vulnerabilities/issues based on their CVSS v3 score by default (and uses CVSS v2 score - when a v3 score is not available). When reviewing and comparing results in the Nessus Console to those same results in Prismthe platform, ensure that Nessus is configured to use a CVSS Base Score of version 23. Otherwise there will likely be discrepancies between the severity rating in Nessus Console and the severity rating in the Prism Platform

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 Prism 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)

...

The ‘Details’ section provides further information on the scan execution itself - pay attention to the CVSS_Score value; currently set toCVSS_V2. If the scan results are based on CVSS version 3, there will likely be discrepancies between the severity rating in the Nessus Console and the severity rating in the Prism PlatformThe ‘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

...

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

...

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 Prismthe platform, we have a single phase into which the scan results from Nessus were imported:

...

Moving into the “Issues Overview” tab in Prismthe 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 Prism the platform will provide the same vulnerability information as found in Nessus (such as the Description, the Solution and the Output), Prism summates 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 Prismthe 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 Prism 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 Prismthe 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 Prismthe platform, you’ll likely see differences in the “Count” (Nessus) and “Affected Instances” (PrismPlatform). This doesn’t mean Prism 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)

  • Prism The platform will report vulnerabilities based on affected Host & Port pairings. Whilst the “Technical Details” for an issue in Prism the platform will still present all relevant output for a vulnerability, Prism 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 Prism 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 Prismthe platform, if 10 occurrences of the same vulnerability were found on the same Host/Port pairing, Prism the platform would report an “Affected Instance” of 1. If the same vulnerability was found across 10 hosts, the “Affected Instances” would be 10