Vulnerability scanners: a view from the vendor and end user side. Original article was published in Information Security Magazine #2, 2016 (in Russian)

Vulnerability scanner is a computer program or hardware appliance designed to detect security problems on hosts in computer network. What kind of problems? Well, problems that may occur if some critical security updates were not installed on time or the system was not configured securely. In practice, this situation often occurs and it makes hacking the systems easy even for inexperienced attacker.

If it is all about checking, maybe it’s possible to do it manually? Yes, sure, but it requires a lot of specific expertise, accuracy and time. That’s why vulnerability scanners, which can automate network audit, have become standard tools in the arsenal of information security experts.

I worked for a long time in the development department of well-known vulnerability scanning vendor and was making a lot of competitive analysis as well. At current time, I use vulnerability scanners as an end user. So, in this article I will try to look at the main problems of this class of products from the vendor and from the end user side.

How vulnerability scanner detects vulnerabilities?

Detection methods are usually well known and uncomplicated: vulnerability scanner somehow detects software version installed on a host. If version is less then secure version of this software (known from the public bulletin) – vulnerability exists and the software should be updated. If not – everything is ok. As a rule, vulnerability scanners try to guess installed versions by opened ports and service banners, or scanner may just have a full remote access to the host and able to perform all necessary commands (it is the most accurate and effective way).

There are also passive scanners (for example, Tenable PVS) that can detect software versions by analyzing network traffic. Like IDS detects network attacks. In most cases, vulnerability scanners does not require installation of local agents on the network hosts. However, in last two years, some vulnerability scanner vendors (Tenable, Qualys) have implemented agent-based scanning in their products. Agent-based scanning is preferable for mobile devices that appear on the network periodically, or the network hosts that can not be scanned with authentication.

If vulnerability scanner is so easy to make and they cost a lot… Why don’t all become VM-vendors?

To make a vulnerability scanner for to check one kind of system is relatively easy. Especially if you want to scan only one popular Linux distro, where all software is installed from official repository (see an example in post “Vulnerability Assessment without Vulnerability Scanner“). In this case you only need to track publicly available security bulletins for this distribution, or even get them from in JSON from aggregator (see my article “Vulners – Google for hacker“). But the more different systems you want to scan, the harder scanner development process become. You will need group of experts for different systems, write a lot of parsers for sites with vulnerability descriptions (or ask Vulners Team to do it ;), understand all nuances of the simplest operations like version comparison and keep an eye on all recommendations of software vendors. That’s why there are not so many vulnerability management vendors on the market and some of them a highly specialized on one particular system (see my article “ERPScan SAP security scanner“).

Knowledge base. It’s impossible to know everything

Knowledge base is the main part of any Vulnerability Scanner. Keep it always up to date – not an easy task. What is up to date means for Vulnerability Scanners?

“Up to date” as “supports all the systems that user need”. Market of IT systems is continuously evolving and become more and more complicated. There will always appear new technologies and products, in which sooner or later somebody will find vulnerabilities. Vendor of vulnerability scanner must constantly track what systems are used by customers, and implement support for these systems in their products with minimal delay. So, it will always be a question of priorities. Users, in their turn, should evaluate vendor’s expertise in the technologies and systems, that are important for the user, BEFORE purchasing  a scanning solution .

“Up to date” as “detects all vulnerabilities for supported systems”. If vendor of vulnerability scanner declares support for the operating system/network device, it doesn’t automatically mean that vulnerability knowledge base for this system/device is complete. And it is important. Scanner will never find vulnerability it doesn’t know. Thus, the end-user may feel false confidence in safety of his network. You can see an example of such situation in my post “When a free scanning service detects vulnerabilities better“.

Database incompleteness may address new and old vulnerabilities.

When a new, critical and “popular” (with name and logo) vulnerability appears, like Heartbleed, Shellshock, or Ghost, leading vulnerability scanning vendors arrange unspoken competition who will release a detection of this vulnerability in the product first. But detection rules for some average unknown vulnerabilities, but still exploitable, may be implemented in scanner with big delay.

The same with older vulnerabilities. Dishonest vendor may add detection rules released after a certain date, ignoring the vulnerabilities published earlier. But the fact that vulnerability scanner vendor ignores some vulnerability, does not mean that attackers do the same.

It’s not an easy task for end-user to figure if scanner’s knowledge base is complete or not. The task become even more complicated, if the vendor doesn’t disclose the list of supported rules for vulnerability detection (plugins). Decent Vulnerability Scanning vendor should honestly describe which user’s IT systems they can adequately assess, and which not.

Even if vendor supports all user’s systems completely and vulnerability scanner has all needed detection rules, still the question remains: were those detection rules implemented correctly?

Quality of scanning. Trust but check and ask uncomfortable questions

We can believe that vulnerability scanning vendor tests carefully detection quality before product release. Well, not really. In most cases. Since vulnerability detection engine, as a rule, is “under the hood” of the scanner, end-user can’t assess if it works correctly. And if vendor hides vulnerability detection logic, this may indicate that it’s not good enough.

If you’re comparing multiple vulnerability scanning products, it is useful to scan the same set of network nodes (of different types) with available vulnerability scanners and ask involved vendors to explain the differences in results. This can help to get rid of one popular misconceptions that all popular vulnerability scanners works the same way, and give approximately the same results. And sometimes it’s can make vendor’s products better 😉 (see my article “Use multiple vulnerability scanners in the name of good“).

Full network scanning. Not so easy as it seems

Almost all vulnerability scanning vendors are recommending to scan all hosts of the network and do it as often as possible. Well, it’s also may also be tricky. If the scanner is licensed by the number of scanned hosts, covering the entire network may be costly. But even if the cost of the scanner does not depend on the number of scanned hosts (read Nessus), it’s important to choose optimal location and number of the scanners. Full scan of one host takes approximately 5-10 minutes and in a large network scanning with one scanner can take an unacceptably long time. But having multiple scanners, can greatly increase network load. Furthermore, the more scanners you have, the hard to manage it. So, it’s necessary to look for the right balance.

East is East and West is West, and never the twain shall meet

Vulnerability scanning vendors try to make their products focusing on the wishes of potential users. And it is right. But, unfortunately significant part of this users (I don’t say most) have no experience with vulnerability scanners, are not familiar with the main concepts of Vulnerability Management and can not truly understand what they want and need. In my opinion, this is the main cause of misunderstandings between VM vendors and their end-users.

It seems like the most VM vendors create their products based on the false belief that:

• client’s infrastructure consists entirely of new hardware and software
• users are willing to put several local agents on their network nodes
• engineers are ready to use cheap Lintel appliances in critical network locations

Each vendor is trying to include in scanning solution own dashboards, task management, reporting, and scanner management systems. This tools are often poorly integrated with existing company products and processes and therefore, sad but true, nobody wants to use it.

Another problem is storing scanning credentials and other critical information (e.g. about infrastructure vulnerabilities and misconfigurations). Typically, the scanner requires privileges administrator, otherwise the results may be incorrect (and it’s may be hard to identify). If you store this sensitive information in some cloud product you should probably trust your vendor very much. However, even if all the passwords/keys are stored in the scanner within your network, you still need additional monitoring to detect unauthorized use. As vulnerability scanner has access to literally any host in the network and knows everything about it, it becomes a very valuable asset and the first target for attacker, it is very important to keep scanner safe: track updates, choose a strong passwords for scanner accounts (read more at “Tenable Nessus: registration, installation, scanning and reporting“).

What to do

At the end of the article I would like to express my vision on vulnerability scanner’s critical functionality. It’s based on my personal experience in development, competitive analysis and direct usage of this kind of products.

In my opinion, for effective Vulnerability Scanning it is critical to:

• ensure that scanner’s knowledgebase is in adequate state;
• ensure that scanning credentials are managed effectively and safely;
• detect, validate, prioritize vulnerabilities and make practical recommendations for remediation;
• integrate vulnerability scanning into your existing infrastructure systems and processes.

And, as I see it, the last two points can not be effectively implemented in ready-made solution, that’s why Vulnerability Scanner should have an API and should allow end-users to do it by themselves.