Vulnerability scanners are tool that identify mis-configured or flawed devices and systems on your network that could be exploited by attackers in order to gain access to your data and systems.

In order to successfully infiltrate access your network, an attacker has two questions they want answered:

• What software and devices are used on the network
• What are the versions of software and firmware in use

Assuming a firewall is already in place to prevent free for all access to your network from the internet, in order to break in, an attacker needs to identify a specific vulnerability and then exploit it.  This is similar to the way that a burglar would stand in the street and eyeball your house to spot any windows left open or doors that have weak looking locks and then target the easiest route into the house.

Imagine you have a web application that runs in a Tomcat server, and during the installation you forgot to remove the default Tomcat Documentation webapp from being published to the internet. Perhaps you thought: it doesn’t matter that a Tomcat manual can be seen both inside and outside of your network. However, the Tomcat Documentation webapp also clearly shows the exact version of Tomcat you are running.

It turns out you are running Tomcat version 9.0.17 which includes a Remote Code Execution vulnerability in CVE CVE-2019-0232.

So simply by trying to access the Documentation default webapp on your Tomcat server’s public IP address an attacker is able to know exactly how to exploit a known vulnerability and execute arbitrary code on your webserver.

If only there was a simple way both to check for these kinds of schoolboy configuration errors and identify any unpatched vulnerabilities sitting on your network.

This is exactly what a vulnerability scan will do – and more besides.

What is a vulnerability scan?

In its simplest form, you can think of a Vulnerability Scan as an NMAP scan with added intelligence.  The Vulnerability Scan will check every open port on each IP address it has been targeted at, and then if the port is open, it will try various techniques in order to try to identify the software that is listening on that open port. These techniques range from simply checking returned headers that declare version numbers through to subtle clues found in meta-data or the format of responses.  Scanning vendors have developed huge databases of information to help identify the software that it finds.  Once the version of software has been identified the Scanner then checks the CVE database for any known vulnerabilities in that precise version of that software product and if any are found, provides a report informing you of the risk and how to patch it to resolve the problem.  The report the vulnerability scan produces serves as a prioritised to do list for your System Administrators so they can patch the vulnerabilities and correct the configuration errors that have made your systems softer targets than they need to be.

Many organisations use their vulnerability scans as a regular health check for their system, running them at least once a month.  This means as soon as a new vulnerability is reported and added to the CVE database it will be flagged on your scan reports so you can take appropriate action as part of your monthly patch cycle.

External scans

Most organisations start with an external vulnerability scan.  These are usually provided as a service on a subscription basis. (See list of Scanning vendors below).  An external scan approaches your network from outside your firewall – just like an attacker would. It scans a range of IP addresses that you define first to identify all the devices it can locate and then to identify common configuration errors and known vulnerabilities for the software you are using.  The scan can usually be configured to run at a certain time of day – overnight is usually chose while systems are less used.  The Scans are designed to be non-intrusive and should not impact the performance of your systems. However, since the primary reason for the scan is to identify software that is not behaving as it should – it is always possible that there could be some unexpected impact on your network. For this reason, network managers often chose to schedule the scans to run during the quietest time on their network.

Internal scans

Internal vulnerability scans are the essential partner of external scans. As the name implies, an internal scan happens inside your network – behind your firewall.  In order for this to happen a scanning device needs to be installed in each network segment so it can communicate with all the devices on your LAN.  These devices are often a Virtual Machine image but can also be physical rack-mounted devices installed in your data centre.

Once you have run your external scans for a few months and addressed all the identified issues, the attack surface of your organisation will be much reduced and hardened.  Some servers which were visible in the scans, are no longer showing up because they are now correctly hardened and configured. Other servers were never visible to the internet. In order to ensure the whole network is secure, it is also necessary to run a scan against all internal devices.

If an attacker is able gain a beach-head in your internal network – through malware delivered in an email attachment into you call centre for example – it is important that all internal systems are correctly patched and configured to prevent further compromise.

An internal scan is also a useful tool for checking that the planned network segmentation has not been broken (and required under PCI-DSS whenever a significant change has been made to the network for this reason).  Running a monthly internal scan in partnership with the external scans is a great way to ensure the health of your security posture.

The CIS Critical Security Controls for Effective Cyber Defence designates continuous vulnerability scanning as a critical control for effective cyber defence.

PCI-DSS requirement 11.2 stipulates the running of internal and external vulnerability scans. Going further PCI-DSS requires a ‘clean’ scan at least once per quarter – this means there are no remaining Critical, High or Medium rated issues identified in the scan.

Web application and infrastructure scans

So far, we have been thinking about infrastructure scans – these focus on the firewalls, routers, servers, NAS devices and so on that are present on your network.  If a server is identified, the scan will try to work out whether its Windows or Linux, and is it running Apache or Nginx as the web server. But what about the web application you have written which runs on the web server?  An infrastructure scan will generally focus on the operating system and web server software and ignore the web applications which run on the server. This is where Web App scans come in.

A Web App scan is a special kind of vulnerability scan which is designed to interact with a web application and will attempt to break out of the web application and access the underlying server or break the authentication of the web app and access data in the same way an attacker would.

A Web App scan will test your web application in order to identify common programming errors or configuration mistakes which leave your data vulnerable to theft or unauthorised manipulation. This includes vulnerabilities such as SQL injection, Cross Site Scripting and common design flaws that violate the OWASP top 10.  Some Web Apps scanners also require you to install a component on the server to be tested in order to gather additional diagnostic information.

When using a Web App scanner, you should ensure both authenticated and unauthenticated scans take place.  An authenticated scan means the Web App scanner will use a valid username and password that you provide and login to the Web App.  This allows the scanner to validate that a logged in user is not able to access data which they are not authorised to see – that is a broken access control vulnerability exists. (see https://secureteamprod.wpengine.com/articles/why-pen-testing-matters/ for an example )

Do I need a pen test if I run vulnerability scans?

Human powered penetration tests are a different but complimentary tool to vulnerability scans. As vulnerability scans are automated software driven services, they come with a lower cost than a human powered penetration test, so it usually makes economic sense to perform vulnerability scans and resolve the issues identified before engaging a penetration tester. While the penetration tester will find all the same issues the automated vulnerability scanner can find – the pen tester is also able to adapt, make intuitive leaps and pursue clues in a way that the scanning software cannot.  This is why, for example, PCI-DSS requires quarterly vulnerability scans plus a penetration test at least once a year.  A vulnerability scanner is very good within the narrow focus of its ability – identifying vulnerabilities. A pen tester will not only potentially identify additional vulnerabilities but demonstrate how they can be exploited within your network and business.