Automatic vulnerability scanning has become a common staple in security routine. Quite often however, security is run as a “project” rather than integrated into the IT process. Naturally this extends to the usage of scanners, resulting in sub-optimal use of such tools. In order to better understand the usefulness as well as limits of such scanners, we should better understand our needs/goals as well as how scanners work and how they can fulfill that role.
By nature, scanners can only identify already known vulnerabilities or very common insecure patterns. They vary in the “aggressiveness” of their detection, with the passive scanners sending only “harmless” (i.e., non-malicious, low-frequency, …) packets to the target systems or even relying on already public/crawled “open” information. More active scanners may send packets that trigger misbehavior on the target system, but usually those probes are designed to be least invasive to the system and not cause outages. Finally, some “automated pentesting” tools may even support modes that are likely to interfere with general operation.
Generally though, the bulk of findings through vulnerability scanning is based on the detection of software versions deployed and matching them with known CVEs applying to those versions. In essence, known-vulnerable software versions are found and the most frequent advisory is to patch the listed systems or remove them from the attack surface.
Vulnerability scans can (in theory) cover a big area of the network and do the bulk of the work when it comes to identifying out-of-date systems. However it is often not immediately clear from the results whether a finding is indeed exploitable, how seemingly harmless vulnerabilities may be chained or whether some software has a vulnerability not listed as a CVE. The latter is especially an issue with custom software (including web sites) that is not distributed commercially. In order to assess the security in this depth, a manual assessment by information security professionals is required. In a penetration test, the professionals will try to find deeper issues in the systems that stem from the complexity of networked systems and would otherwise not be uncovered by looking at nodes in the network separately. Due to the manual work, the scope is more limited.
Red Teaming is a related technique where the professionals additionally try to simulate “real” attackers by employing obfuscation techniques in order to compromise the systems more stealthily. The goal of a red team engagement however is not to find “the most” issues but to test/train the readiness of the defensive blue (defense) team and their methods, tools and skills to detect real threats. Thus, this is more akin to an attack simulation.
Due to the manual nature of pentests and red teaming engagements, it is often reasonable to rotate service providers. This rotation uses their difference in focus areas best and ensures ideal coverage.
In contrast, automated scanners vary much less, as all end up using the same CVE databases. In addition, vulnerability scanners produce many false positives which result in burden for the IT staff — employing multiple scanners in parallel multiplies this work while only seldomly adding benefit.
A vulnerability scan may include all publicly reachable hosts, internal networks (with additional scan probes deployed within the company network), or a mixture of both. They may be configured to scan the targets as-is or bypass firewalls to simulate a breached perimeter/defense line.
Naturally, more visibility for the scanner (internal probes, bypassing of firewall, etc.) will yield more complete results. At the same time, it is quite common for scanners to produce a large list of findings, and further growing that list is not always helpful. Instead, prioritization of especially exposed (i.e., publicly reachable) or sensitive systems may be reasonable.
Due to the restrictions in their accuracy and depth, vulnerability scanners cannot be relied upon to always and timely identify vulnerable systems. Rather, they can serve to provide additional visibility when data sources (e.g., asset management) are unreliable to provide up-to-date version (and thus vulnerability) information.
With the proper goals in mind, scanning can provide a rather inexpensive and quick method to get a first overview of the attack surface of an organization. If the initial goals and expectations are set correctly, a remediation of critical and high risks is a viable short-term strategy. In the long term it is recommended to allocate increased resources to automated update strategies and asset management to provide a higher quality data source for vulnerable systems (”continuous vulnerability scanning & management”).