Penetration testing, in a couple of ways, is the front line of the battle between cracker and security personnel.
Put simply, "pen testing" is using hackers -- either on staff or from outside -- to try to find vulnerabilities in systems. It's precisely like a bank paying somebody to try to break into the vault.
It is an extremely effective and somewhat disconcerting area. It's effective, of course, because it cuts right to the chase of whether the organization's cyber security is adequate. The scary element is inviting folks to take a shot at your defenses. What if the folks you hire aren't as honest as they seem?
An even more intriguing issue is what must be done if they find a problem. Suppose a pen test spots a problem, and the organization decides not to address the issue. The next week, a criminal exploits that very vulnerability. Does that make the organization more liable than if it didn't know of the problem? Must it report the fact that it knew the opening existed?
This ComputerWorld piece doesn't get into those questions. It does, however, offer an extremely sobering look at what PatchAdvisor found when it tested a civilian contractor to the government. The tester was able to access a "major FBI crime database" in less than one business day. Perhaps even more sobering was the revelation that security was so lax, the pen testers had an easy time gaining access to data that should be well protected. The piece links to useful sidebars on steps to penetration tests and information on free tools.
This MSDN post goes inside penetration testing. The writer says that there has been a "renaissance" in the field and the old image of a lone genius sitting at a computer until 4 in the morning trying to breaking into an enterprise no longer is valid. The writer describes the planning of a test.
The most interesting element of the feature is a discussion of the types of pen testing. There are environment attacks (which place the system under attack in the wider context of what the software connects to or uses); input attacks (the use of untrusted sources to attack the system) and data and logic attacks (the exploitation of faults within the applications). The writer concludes that penetration testing is different than functional testing -- making sure applications work -- both because it proceeds without documentation and can't assume logical actions on the user's part.
Clearly, choosing a pen testing vendor is an important issue. The organization wants a company that will produce results -- and that won't use them. SecurityProcedure offers an outstanding list of steps to choosing a good vendor. Prospective clients should confirm that the company has liability insurance; get references; determine the scope of testing; avoid firms that work for free or employ former black hats; make sure the firm is conversant with regulations in the field; note the IP addresses of the testing devices; make sure that the test has a definitive end time; get all data connected with the test; and meet the testers themselves, not just the sales team.
This interesting post, which is more or less a game plan for a penetration test on a travel site, begins by outlining four steps (create a threat profile; create a test plan; perform the test; and prepare a report) to a penetration test. The next section discusses the threat profile. For a travel site, this profile includes such mischief as buying tickets at lower prices than advertised or changing the itinerary of other users. The piece briefly discusses creation of the plan and the beginning of the test itself.
As long as the CIO and CSO have to report to the CFO and the CEO, they will have difficulties, since security doesn't generate revenue. The writer of this I.T. Wales piece tries hard to explain how to create a return on investment (ROI) for penetration testing. The writer makes several very valid points: A pen testing program can lead to a lot of savings. The bottom line, however, simply is that good security doesn't make money.