How to read a Nessus scan report

Last Updated on September 15, 2023 by Dave Farquhar

Reading and analyzing a Nessus vulnerability scanner report is an underrated skill. Frankly, I see a lot of misuse and abuse surrounding Nessus scans. So let’s talk about how to read and analyze a Nessus scan for the purpose of understanding and solving problems.

You can read it in the user interface but I recommend exporting a CSV so you can sort and filter. The exact CSV format has changed a bit over the years so they may not be in this exact order. But this will get you started. The most important columns are all here. You’ll find it very similar to reading a Qualys scan report.

For reference, I used the sample file here: https://github.com/derekmorr/nessus-csv/blob/master/nessus_test.csv

Nessus file columns explained

The data in a Nessus scan generally takes 20 to 25 columns in CSV format. Some of them are more useful than others. The columns useful to a vulnerability management professional may not be the most useful columns to a remediator/system administrator and also may not be the most useful ones to a penetration tester.

I’m a system administrator turned vulnerability management professional. Learning to read a Nessus scan changed my career for the better. So I’m happy to pass that along in hopes it helps someone else too.

Plugin

This is Tenable’s tracking number for the vulnerability signature. Scanners use vulnerability signatures much like antivirus programs do. Plugins are what Tenable calls its vulnerability signatures, and they are written in a scripting language called NASL. But the main thing to remember is this is a proprietary tracking number.

Plugin Name

This is the title of the vulnerability check. It should be fairly self explanatory. When it isn’t, the synopsis or description columns can provide further enlightenment. If you’re not already familiar with the vulnerability in question, it’s a good idea to scroll over to the synopsis and description columns to familiarize yourself. I’ve seen people get in trouble by jumping to conclusions just based on the title. That’s like trying to speak intelligently about The Great Gatsby without even reading the Cliffs Notes. You mean it’s not a book about a magician?

About 20,000 of these things turn up every year so I don’t expect you to read 200 pages about every single one. But good security analysis requires more than highlighting the plugin name column and making a pivot table.

I will sometimes filter on this column on certain keywords, like Adobe Reader, Google Chrome, and other things I’m used to seeing frequently, to get an idea of what percentage of the problem the usual suspects are contributing to any given Nessus vulnerability scanner report.

Family

This is the general category of vulnerability, from Tenable’s point of view. I’ve seen people use this column to classify the vulnerabilities, but I’ve seen others who’ve never needed this column. I’d put myself in the latter category. The plugin family doesn’t line up well with the usual suspects I mentioned in the previous section. It’s better to use your own keywords. Read a few scan reports and you’ll get a good feel for the kinds of things that turn up frequently in your network.

If you get the sense that I think this column is overrated, you’re right.

Severity or Risk

Now we’re talking. This is the severity of the vulnerability: critical, high, medium, low, or informational. Critical, high, medium, and low should be pretty self explanatory.

Let’s talk about those informationals.

The patch report

Some people will tell you to ignore informationals, but they are good for troubleshooting, and there’s one informational called the patch report that’s absolute money. It’s a list of updates to deploy, deduplicated, with all the superceded patches accounted for, to get a clean system with the least work. There’s another one that tells you if the system is wanting to reboot. If you’re applying updates and still see vulnerabilities in your Nessus scan, that pending reboot plugin is the reason why.

Finding malware(!)

Years ago, someone asked Paul Asadorian, the former product Evangelist for Nessus, how you know if you’re really good at using the product. He said when you find malware on a system as a result of a Nessus scan. If you ignore those informational findings, you’re much less likely to unlock that achievement in your career.

Finding compensating controls

I’ll give you another pro tip. A former employer was desperate to secure a contract with a well-known restaurant chain. The CEO asked me to talk with them in a last ditch effort to sell them some business. The discussion was not going well. But at one point, one of their security analysts said it would be nice if they could know when a vulnerability is mitigated due to the environment. I spoke up. I said that kind of detail is usually in those informational findings. You can use those to track what systems are behind a firewall, what systems have antivirus or EDR tools installed, and other evidence you may need to determine how well protected a system is. They went from being completely uninterested to ready to sign a deal right after I said that. Being able to do this may sound less impressive than finding malware, but you’ll do this more often.

Explaining false positives

I will give you one more. There will be informational findings about authentication. It’s a fairly long list, but they have a knowledge base article about it. I recommend you bookmark it, or print it out and hang it in your cubicle. Anytime your vulnerability scan results seem incomplete or wrong, the first thing you want to check is authentication.

Pro tip: If you’re finding more than three false positives per million findings, that’s a very good sign your authentication is failing or your scanner account doesn’t have enough permissions. Per Tenable’s own recommendations, scanner accounts must be administrative in nature.

IP address

This is the IP address of the system that had the finding. Depending on your environment, it may or may not be the best identifier, but that’s why they give you three others.

Protocol

This is the protocol Nessus used to find the vulnerability. In the right hands, this is useful information. I have also seen people come to weird conclusions based solely on this column. If you really know your ports and protocols, this can be a useful column. If you don’t know networking very well, this column can produce red herrings just as easily as it can help you.

Port

This is the TCP or UDP port that Nessus found the vulnerability on. This can be useful information, especially for the system administrator trying to remediate the vulnerability. One good example is when you find an SSL or TLS related vulnerability. When we see SSL or TLS, our mind immediately goes to port 443. But SSL and TLS can live on other ports, so knowing what port is vital for fixing those vulnerabilities. I’ve gotten used to seeing these, because that seems to be something not everyone knows.

It doesn’t seem like I need this column very often, but when I need it, I need it badly. This, in combination with the protocol, can be useful for tuning your IDS or IPS if you’re into crossing silos.

One example of when I use this column is when determining if a vulnerability is active or dormant. If the vulnerability exists in a service that normally listens on a port but this column is empty, that’s a good indicator the service is disabled. That doesn’t mean the risk is fully mitigated, since enabling and starting a service is trivial. But it may mean that particular vulnerability isn’t the biggest problem in this particular Nessus vulnerability scanner report.

Exploit

This is just a simple yes or no. If Tenable knows about an exploit for this vulnerability, it will be yes. Otherwise it’s no. All other things being equal, exploitable vulnerabilities present a greater danger than vulnerabilities that don’t have any known exploits. But this is just a simple yes or no, it doesn’t give any indication how reliable or widespread the exploits are. If you don’t have any kind of threat intelligence, this can help you prioritize things until you get something better. It’s crude, but a lot of companies use it for prioritization.

MAC address

This is the hardware address of the network card where Nessus found the vulnerability. It also isn’t necessarily the best identifier, since some virtualization platforms give all systems the same MAC address, and it is not at all uncommon for systems to have multiple network cards. But it’s another clue when you need to identify a system.

DNS name

Now we’re talking. This is the DNS name of the host you scanned. This is not only excellent identification information, it’s also fantastic for troubleshooting. If you notice DNS names are inconsistent between scans, make sure all of your scanners are using the same DNS servers. Vulnerability scanners are very good at finding problems in your network, and this column is one of the places they are likely to show up. My workaround is to use the same DNS servers in the same order on all of my scanners, but ideally all of your DNS servers will return the same results all the time.

I also know that’s easier said than done, especially since my days as a DNS administrator ended in 2005. I was the administrator of evacationbibleschoolstudies.com, along with 200 other similar domains that weren’t my idea to register, so look upon my works and despair! In all seriousness though, 2005 was a long time ago so I can’t offer much help, other than to say it’s not trivial.

NetBios name

NetBios is a Windows networking protocol, so you will usually see a NetBios name on a Windows system. You may also see it on non-Windows systems. If you see it on a Mac or Unix like host, that tells you that system is configured to play nice with Windows systems. This column is also a useful identifier, it’s just not as universal as DNS name.

Here’s another cool trick. When the DNS name and NetBios names don’t look anything alike, that is a good indicator that not everything is healthy on your network.

Plugin text or plugin output

There are some columns in the output you can safely ignore. This column is not one of those. This column has the details of what the scanner found and where it found it.

Here’s how to read and analyze Nessus plugin output in a vulnerability scanner report.

If you see the name of an update here, with a vendor tracking number, that’s a good indication that the update the scanner is looking for was never applied to this specific computer. If it’s a path in the file system or the Windows registry, that is an indicator that an update was applied, but one or more parts of it did not take effect. It could be the system didn’t reboot after applying the update, and rebooting the system will clear the finding. It could also be that the file didn’t update, or some other process after the fact reverted the file. If a reboot doesn’t clear the issue, reapplying the update frequently will. Failing that, Windows stores logs in ETL files that are frequently helpful in troubleshooting. A good system administrator can use the information in those to fix the problem.

I know this because I was a system administrator who knew how to read vulnerability scans. I fixed 800,000 vulnerabilities in my career before moving to the security side of things.

First discovered and last observed

These are the dates the vulnerability first turned up in a scan and most recently turned up in a scan.

Vulnerability management comes down to fixing the right things and fixing them fast enough. So these two columns are incredibly useful to a security professional. Maybe not so much to a system administrator. But if they are curious whether an item in the scan is new or old, these columns will answer that question.

Exploit framework

If an exploit exists, this column can give some insight into where to find it. This is a little more useful than a simple yes or no, if you are willing to dig into that detail. If you’re a pentester, this is probably the money column in the Nessus vulnerability scanner report for you. For a blue teamer like me, this might give me a crude indicator of exploit maturity but outside of that I don’t need this column much.

Synopsis and description

These are human readable details of what the scanner found. Read these two columns when you run into a vulnerability you haven’t seen before.

Solution

This tells you how to fix the problem. It may provide a vendor update, a workaround, a mitigation, or any number of things. This is another column that is absolutely essential. If all I have is a DNS name, plugin output, and solution, I can function.

See also

This will frequently provide useful links to more information about the vulnerability and/or the solution.

CVE

CVE is the universal industry standard tracking number for vulnerabilities. Not everything in these results has a CVE, and security professionals care more about the CVE than system administrators do, but this is a useful, vendor neutral tracking number. As opposed to the plugin number, which is completely specific to Tenable. One plugin can (and frequently does) cover multiple CVEs.

From time to time someone will try to tell you to ignore anything that doesn’t have a CVE in it. That’s not good advice.

Publication date

This tells you when the vulnerability was published. This can be helpful so you can determine if you found a new instance of an old vulnerability, or if this is something new.

If you see a sudden spike in your vulnerability counts, this column is a good place to look. If you see a whole bunch of recent dates in this column, that’s why your vulnerability counts went up.

I know for some people this may seem obvious, but I get asked this question a lot.

VPR score

You may not get this depending on which level of product you are buying, but this is a measure of severity with threat intelligence incorporated into it. On a scale of 1 to 10, with 10 being the highest, you can do worse than sorting on this column and fixing things in that order.

CVSS

CVSS is the industry standard way to score vulnerability severity. It uses a scale of 0 to 10, with 10 being high. I’d rather not get into the pros and cons of this particular scoring system, because it tends to turn into religious debate. Suffice it to say people make a lot of incorrect assumptions about this scoring system, that it’s either a bell curve or an even distribution, and neither is true. It tends to be skewed towards sevens and above. If you want a weird world where 80% of vulnerabilities are above average, choose this hill to die on.

VPR isn’t perfect, but its distribution is much more useful for figuring out what order to fix things in. CVSS version 4 may fix this, but at the time of this writing, we live under version 3. The problems with CVSS are where the idea to prioritize based on exploitability came from.

Analyzing Nessus vulnerability scanner reports for fun and profit

I hope that helps you. There’s a fair bit of analysis that can and should go into a Nessus scan. Otherwise it’s easy to miss what it is your scanner is asking you to do.