Tag Archives: Tenable SecurityCenter

Tracking software versions using Nessus and Splunk

Let’s say you have already exported scan results from Nessus or Tenable SecurityCenter to Splunk using HTTP event connector, or in some other way. And you see that some critical software vulnerability was published. For example, this month Jira critical vulnerability. How to find out, do we have vulnerable servers in our infrastructure or not?

Nessus plus Splunk

Of course we can start a new Nessus scan to detect vulnerable hosts. However, Nessus plugin for this particular vulnerability may be released with a big latency and you will not find this vulnerability in your scans. So, it’s may be faster just to search for detected Jira servers in available scan results using Splunk searching mechanism.

Continue reading

Tenable.IO VM: connected scanners and asset UUIDs

I have already wrote earlier about new features of Tenable.io VM cloud vulnerability scanner. In this post, I would like to show how Tenable.io cloud service works with Nessus scanner deployed inside your network. Spoiler! Everything is very different from Nessus and Tenable SecurityCenter.

Nessus registration process

I also would like to demonstrate how Nessus creates Asset IDs (Tenable UUIDs) on the the host during authenticated scanning and how can we get this IDs from the scan results.

Continue reading

Parsing Nessus v2 XML reports with python

Previous post about Nessus v2 reports I was writing mainly about the format itself. Now let’s see how you can parse them with Python.

Please don’t work with XML documents the same way you process text files. I adore bash scripting and awk, but that’s an awful idea to use it for XML parsing. In Python you can do it much easier and the script will work much faster. I will use lxml library for this.

So, let’s assume that we have Nessus xml report. We could get it using Nessus API or SecurityCenter API. First of all, we need to read content of the file.

Continue reading

Installing Nessus for SecurityCenter on laptop

The great thing about Tenable SecurityCenter: when you buy it you also get hundreds of licenses for Nessus.  You can google different types of SecurityCenter bundles with “SecurityCenter Continuous View – On Premise” request. “Scanners” here mean SC scanners:

You will need these scanner licenses to deploy Nessus hosts on your network, connect them to your Tenable SecurityCenter and manage scan process using SecurityCenter via graphical user interface or API. Of course, with all the restrictions on amount of IP addresses that you can scan.

At the same time, these Nessus for SecurityCenter servers are fully functional. Technically this servers are the same as Nessus Professional. Nessus for SecurityCenter has the same web interface, where you can create multiple user accounts, manage the scans in GUI and API, scan any amount of IP addresses. Scan data will be stored locally on your Nessus server and your SecurityCenter will not see it or use it in any way. This is really great. And I hope it is a feature and not a bug.

However, there are some differences. Nessus Professional downloads security plugins and makes activation using remote Tenable severs. Nessus for SecurityCenter does these things using SecurityCenter in your network.

So, when you have such a great amount of Nessus licenses you may want to install one on your own laptop. It might be really useful for debugging. For example, when you are developing your own nasl scripts, to enable them in Nessus, you will need to restart it. And you will not probably want to do it on the Nessus server where dozens of scanning jobs are running.

In this post I will try to install Nessus on Centos 7 in VirtualBox, configure port forwarding, activate and update Nessus plugins with SecurityCenter.

Continue reading

Fast comparison of Nessus and OpenVAS knowledge bases

In my opinion, quality of knowledge base is the most important characteristic of Vulnerability Management (VM) product. Maybe it’s because I have spent significant amount of time making different security content for vulnerability scanners and this is some form of professional deformation. 🙂 The fact is that nowadays we have dozens of VM solutions on the market, which have very different knowledge bases and thus different abilities for detecting vulnerabilities. And really nobody talk about this. I can recommend related post “Tenable doesn’t want to be Tenable anymore” and especially HD Moore’s comment to that post. It describes the reason why nobody interested now in quality of detection. Maximum what we, end-users, can hear from the vendor about it’s knowledge base is an amount of vulnerability checks: 40000-80000 and approximate list of supported systems. There is a massive false belief that detection quality of the products is approximately the same and it’s better talk about dashboards, reports, SIEM-like capabilities. To demonstrate that the difference actually exists I made a pretty primitive comparison of Nessus and OpenVAS knowledge bases.

I chose these two products, mainly because information on their NASL plugins is available at Vulners.com. As I also wrote earlier how you can use easily parse Vulners archives in python, so you can repeat it for yourself. I talked about this topic at Pentestit webinar about Vulners. If you are familiar with Russian, you can also check this out. 😉 The slides for this presentation are available here.

Why I call this comparison fast and primitive? I don’t define the structure of KBs for this product and don’t carefully map one nasl script to another. I suppose it may be a theme for another posts. Instead I am looking at the CVE links. If two scanners detect can the same vulnerabilities, they should have the same CVE links in all the NASL scripts, right? In reality we have a great difference between the products and more than a half of the CVEs can’t be detected by using both of them.

CVE links from NASL plugins

All CVEs: 80196
OpenVAS CVE links: 29240
Nessus CVE links: 35032
OpenVAS vs. Nessus: 3787;25453;9579

Continue reading