Penetration Testing: Part 1
The Free Dictionary defines penetration testing as “a test of a network’s vulnerabilities by having an authorized individual actually attempt to break into the network. The tester may undertake several methods, workarounds and “hacks” to gain entry, often initially getting through to one seemingly harmless section, and from there, attacking more sensitive areas of the network.”
Penetration testing has grown from what was in the early 1990s widely viewed as a curiosity and even as a dangerous and unethical activity to a widely-accepted, widely-used information security activity today. Organizations were at first nervous about conducting penetration testing, in part because at the time most attempts to penetrate systems were perpetrated by cybercriminals and rogue employees. The fact that “high roller” consultancies such as the “Big Four” started to offer penetration testing conducted by technical experts without criminal backgrounds and with well-defined ground rules almost certainly had more to do with penetration testing gaining widespread acceptance and respectability than anything else.
Today penetration testing is widely used for a number of different purposes, including:
• Determining the presence and pervasiveness of security-related vulnerabilities in hosts, networks, applications and databases.
• Providing information needed in conducting risk analyses.
• Identifying contingent risks, e.g., the probability of one host being compromised given that another host on the same network is compromised.
• Testing the security posture of an organization
• Achieving compliance, e.g., PCI-DSS compliance.
• Countering or supplementing the findings of security audits.
Much confusion concerning the relationship between vulnerability assessment and penetration testing exists. Vulnerability assessment means making a best guess concerning which particular vulnerabilities are present in hosts, network devices, applications and databases. The most widely used vulnerability assessment method is to conduct remote vulnerability scans using tools such as Nessus, eEye/Retina, Qualys, Saint, and McAfee Foundstone. One or more of these tools is typically loaded on a server outside of (and often also within) an organization’s internal network and used to scan remote systems, devices and applications on a cyclic basis, e.g., every month. Vulnerability scans almost without exception do not provide conclusive evidence concerning the presence of vulnerabilities, however. Instead, they almost always merely show that a vulnerability could exist, based on reaction to input after connections to target systems were made. Certain kinds of responses on the part of services running on the target systems as well as operating systems themselves are known to be associated with identified vulnerabilities. The problem is that in almost every case vulnerability scans do not go farther–you cannot really be sure of the presence of any vulnerability identified by a vulnerability scanner.
Before I discuss how you can be sure of the presence of any given vulnerability, I must first say that remote vulnerability scanning in and of itself will result in identification of only some, but not all of the vulnerabilities within an IT environment. Remote vulnerability scans are typically partially or fully blocked by security controls at external and internal gateways and routing points as well as by personal firewalls and other host-based control mechanisms. A vulnerability on an internal host may thus not be discovered because the scan for that vulnerability did not reach the targeted service on the target host. Additionally, vulnerability scanners go only so far. Given that they are almost without exception remotely launched, they cannot identify vulnerabilities that can be exploited only by a locally logged in user. For a thorough vulnerability assessment, therefore, you need to also assess vulnerabilities that are internally but not externally exploitable. Internal vulnerability scanners help in this respect, but many long-timers in the infosec arena (myself included) feel that hands-on inspection of hosts and applications by technical security experts is required for a genuinely complete vulnerability assessment.
A penetration test goes farther than a vulnerability assessment in that in a penetration test, the goal is to actually break-into a system and/or take control of or trick a Web application or network device in some manner. The proof is in the pudding, so to speak. A vulnerability assessment shows that vulnerabilities could be present, whereas a penetration test conclusively demonstrates that vulnerabilities are present. Penetration testing, especially effective and thorough penetration testing, requires more planning, effort and care than does vulnerability scanning, but the results of the former are almost without exception more valuable because of their validity.
Many times I have seen consultancies and individuals offering alleged penetration testing services, when all they really offer is vulnerability scanning. Lamentably, potential customers too often look only at the price when they evaluate RFPs for penetration testing services. A one-person shop that works out of a home garage might bid something like $6000 for what an RFP describes as a penetration test, whereas to perform a quality penetration test, one that provides conclusive results, might realistically cost five or six times that much. You get what you pay for. If you are in need of penetration testing services, be careful of “low ball” bids. You are not likely to get much for your money.