When is the right time for a vulnerability scan? Which teams should you involve? And how could the ongoing IT operation be affected? Vulnerability scans are one of the key measures of a security strategy. Our checklist shows how your scan runs as efficiently as possible and which hurdles you can already consider in advance.
1. Start planning the scan early enough
Should a scan be carried out by an external service provider, it makes sense to plan the framework conditions (points 2-10) early enough so that all information is cleared up and obtained at the start. This will save you unnecessary time and can start with the vulnerability scan.
2. Obtain consent from all system owners
Especially with externally hosted systems or scans of external IP addresses, it may be necessary to inform any provider in advance of the vulnerability scan or to obtain a prior consent. In the case of outsourcing contracts, this can possibly be negotiated in advance.
Particularly problematic applications can be on so-called shared platforms or in the cloud. It will not be easy to scan servers that contain data and applications from multiple customers!
3. Include operational administrators or the monitoring team
A vulnerability scan can appear like an attack in a firewall, IDS / IPS, SIEM, or other monitoring systems, provoking a lot of logs and false positives. The respective editor groups should, therefore, be informed in advance and included.
4. Configure the vulnerability scanner policy correctly
If a vulnerability scan is performed for the first time, you should take the time to thoroughly configure the scanner. While most scanners provide useful results in the basic configuration, you run the risk of overlooking important vulnerabilities if the scanners are not adapted to the target environment.
For example, printers are not always tested by default because they may be very unstable to vulnerability scans. But especially printers are often affected by “exciting” data leaks. If they are still in the executive suite and regularly print or scan confidential documents, they must be included as potential weak points in advance.
5. Use Safe Checks (or not)
Most manufacturers offer an option that uses “only secure scanner plug-ins”. This setting has the background that even the mere detection of a security vulnerability can lead to compromising the corresponding service or server – point of denial of service attack. Here it is important to weigh up whether you would rather receive more information and thus risk compromising stability, or rather “play it safe”, that there are no negative side effects.
Attention: No reputable service provider or manufacturer will promise you that nothing can go wrong with a vulnerability scan. A small residual risk always remains.
6. Scan at the right times
As noted in point 5, a vulnerability scan can potentially compromise systems or use narrowband LAN / WLAN connections. At the same time, you can only reach as many client systems as possible over the network during business hours.
So it makes sense to scan clients and non-critical servers during the day. On the other hand, you can scan high-critical servers outside of normal business hours or even on a defined maintenance day. Once you get a feel for how your systems react to vulnerability scans, you can then run the scans more frequently and at different times.
7. Credentialed scans: see more from the inside
In addition to the pure active network scan “from the outside” most vulnerability scanners also support so-called credentialed scans, in which you give the scanner login data and this logs in to the target systems. Now the scanner is also able to detect vulnerabilities in programs that are not actively “listening on the network” (client applications, non-active programs or server services with firewalls).
8. In the evaluation, it depends on the right know-how
Each vulnerability scan generates a lot of information – some critical, many uncritical. The manufacturers already offer quite a good pre-classification here, but it can also happen in the wrong circumstances that a handful of uncritical or even informative scan results combined result in a system being compromised.
This information is usually linked only by experts with a lot of knowledge of the matter. Nevertheless, do not be discouraged to lend a hand. Our tip: Study the results of the scan yourself, but also have an expert look at the results, eg. For example, identify configuration vulnerabilities that you may not have noticed.
9. Scan regularly
A single vulnerability scan is always just a snapshot! In order to generate meaningful key figures and an increase in internet security of one’s own network transparent and evaluable, a continuous vulnerability scan is required. For example, it is possible to have vulnerability scans done at regular intervals or by an external service provider.
The larger the environment to scan, the more meaningful it is to rely on complete vulnerability management solutions. In addition to the pure scanners, they provide a platform for storing and correlating the vulnerability history. That way, over time, you can keep track of how the vulnerabilities in your network are evolving and see at a glance whether the next Shellshock, Heartbleed, or POODLE vulnerability has been patched on your systems.
10. The scan is just the beginning
The vulnerability scan is only the means to an end. After the vulnerability scan evaluation, it goes to the processing of the finds. Incidentally, a good service provider should never give you the bare scanner reports here and then leave. The biggest added value comes from manually evaluating and prioritizing the scans on your environment, as well as suggesting solutions and assisting with queries, effectively closing those gaps in the system.