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.
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.
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.
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.
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.
All CVEs: 80196
OpenVAS CVE links: 29240
Nessus CVE links: 35032
OpenVAS vs. Nessus: 3787;25453;9579
This is my personal blog. The opinions expressed here are my own and not of my employer. All product names, logos, and brands are property of their respective owners. All company, product and service names used here for identification purposes only. Use of these names, logos, and brands does not imply endorsement. You can freely use materials of this site, but it would be nice if you place a link on https://avleonov.com and send message about it at firstname.lastname@example.org or contact me any other way.