Penetration Testing is a security practice during which some trusted party attempts to detect and exploit weaknesses in a system's security. It is possibly one of the more fun aspects of security work, as it is the closest a legitimate ‘white-hat’ hacker can get to the sort of fun the black-hats get up to. (With the additional benefit that so long as you don't do anything stupid like bringing down a production system, the worst thing that'll happen if you get caught is having to write “intrusion detection systems seemed adequate” in the final report).
Penetration tests are also very easy to get completely wrong.
The simplest form of penetration test (and the first step in any) is the vanilla vulnerability scan. Using a tool like Nessus, you can automatically scan a host for the presence of thousands of different known vulnerabilities, and get a nice formatted report of the results. Vulnerability scanners are thorough, and very effective. It is, however, a good idea to have the results evaluated by someone who is well-versed in security practices, to assess the relative risks of each discovered flaw in the context of the network, and beyond the “High, Medium or Low” rankings supplied by the tool1.
Vulnerability scanning finds networked systems that are mis-configured or insufficiently patched. Beyond vulnerability scanning, there are degrees of active exploitation of vulnerabilities that range from a simple extension of the network-only attacks, to a full-blown Tiger Team authorised to attempt anything from social engineering to an attempted physical break-in.
The extent to which you carry out penetration-testing depends entirely on the risk profile of the assets you are attempting to protect. If you only feel it necessary to determine your protection from random Internet crackers, and Nimda/Sapphire-style worms, the automated tests should be sufficient (worms particularly rarely exploit vulnerabilities less than six months old, that can be picked up by any scanner). If your concerns are industrial espionage, veangeful ex-employees or curious government agencies, you may go significantly further.
The biggest mistake made with penetration tests, however, is to misinterpret the results.
Security is a continuum, not an absolute. For every asset you want to protect, you have to determine how much it is worth protecting, and who you would be protecting it against. For example, the public webservers of the Coca-Cola Corporation would be a prime target for wannabe website defacers, anti-capitalist protesters and so on: people with few resources to mount a sophisticated attack. And even if the site were defaced, it would only really cost the company a few days embarrassment and some time rebuilding the machine.
On the other hand, the “secret formula” for Coke itself2 would be a different proposition: the potential loss would be enormous, and one would imagine that if anyone was after it, it would be a significant act of industrial espionage, with sufficiently more resources behind it, and thus a greater range of things that the company would need to protect itself against.
So anyway, when commissioning penetration tests, you should have a very clear understanding of what particular kind of threat you are looking to protect your network from, based on the risk profile of the assets subject to the test. If the test is not matched to the level of defense, then it is worthless. Of course if your network is only designed to be proof against disinterested crackers, a military-grade tiger team will have no trouble breaking in. That proves nothing. On the other hand, neither does knowing that the secret formula for Coke can't be recovered by the equivalent of a random teenager looking for DDOS drones.
Secondly, if your penetration test is matched to the level of protection you expect from your network, then the correct result of the test is that no vulnerability should be found. This is the only acceptable result from a properly calibrated test.
Thirdly, and this is the most important point. If the penetration finds some vulnerability in your infrastructure, the correct response is not to patch just that vulnerability, and then count yourself lucky that you checked for it. While patching the discovered flaw is the first thing you should do, it is by no means the end.
A successful penetration indicates something more than a particular security flaw. It indicates some systemic flaw in network security policies or practices. The network was designed to be proof against a certain class of attacks, and it was found not to be. Why wasn't the installed software up to date against security patches? Why weren't the operators sufficiently educated to spot the social engineering attack? Why didn't anybody notice when the server started behaving out of the ordinary?
A decent systems administrator can secure a server—shutting down unnecessary services, updating necessary ones to the latest security patches, setting up suitable firewall rules—just as quickly and effectively as a vulnerability scanner can check it for known holes. A properly secured server is also far more likely to be safe from future, unknown attacks than one that is reactivley patched when problems are found. The question, therefore, is why wasn't this done?
A penetration test is useless in the absence of a well-implemented security policy. For every vulnerability found and fixed, you must assume ten more will be uncovered tomorrow, and will remain open until next time you perform the tests. The job of penetration testing is as an auditing tool: a validation that existing practices and procedures are sufficient to protect the network. If the penetration is successful, it is to those practices and procedures that management should return, to examine how they could be better implemented, or more clearly communicated to employees. Not to fix the problems with the last test, but to ensure that the next test comes up empty.
1 The author is a network security consultant, so there may be some self-interest in that statement.
2 I actually have no idea if the formula for Coke is a secret or not. It's just an example.
