By performing non-invasive tests, companies can avoid disruption of service while a competent vulnerability assessment is being performed.
There are two methodologies used for performing vulnerability assessment regardless of patch assessment or compliance verifcation. One philosophy revolves around the need to penetrate a system to prove its vulnerability and the other uses available information to postulate the status of the vulnerability. Longstanding discussions have centered on the merits of either type of scanning, as well as their potential liabilities. In summary, since a vulnerability assessment scanner emulates an attack, each of these methods mirrors an attacker’s style for compromising a host.
The Smash-and-Grab: Taking the Low Road
Proponents of destructive security auditing (intrusive scanning) cite the ubiquitous availability of attack scripts for vulnerability exploitation. They hypothesize that by attacking a system in the exact same manner as a potential attacker, more accurate results are best achieved.
Without a doubt, there are some merits to this smash-and-grab approach. By using a script to automate an attack, a penetration scenario where machine access is attainable proves that the device was vulnerable to an attack and ultimately could be compromised. However, utilizing this approach is problematic in that the audit trail is incomplete and potentially creates more questions than answers. For example, many attack scripts available on the Internet are flawed and can result in a false sense of security in the form of a false negative.
That is, they do not function as desired even if the system being targeted is truely exploitable. Unsuccessful penetration tests based on potentially bad scripts can give a false sense of security. Vulnerability assessment tools that use intrusive scripts can be harmful because they leave the system open to future attacks that would normally not be exploitable or worse, deny critical business functions from operating correctly. Smash-and-grab vulnerability testing has a propensity to disable services for the duration of the attack. This means that while a service is under attack, that service may not be available for its normal use and an entire network can be immobilized, blue screened, or worse, the attack could penetrate the network and create a new risk surface for real attacks.
Finally, perhaps the biggest argument against smash-and-grab testing is that it creates a corrupt testing environment. By directly performing attacks against a system being audited, the attack script can push the system into an unknown state—or completely disable it—making the remote system useless for further testing and virtually eliminating the possibility of attaining detailed vulnerability reports against this device from future tests.