Penetration Testing is often sold as the mechanism to highlight when security doesn't work. By contrast, it can also serve to highlight when it does.
I recently watched a video of a talk given at 44CON 2012 in London, where the speaker highlighted a situation where, through pulling an April Fool's Day prank on the CEO of the company, they discovered that their Intrusion Detection System, that monitored the network for suspicious activity, detected what they were doing and alerted them to it. They then took this information to the CEO and created a set of policies to deal with that scenario should it happen again.
Many security companies would think that being unable to prove that a company has gaps in its security is a failure, and would certainly feel that, should any monitoring systems in use alert them to their activities before they've completed their assessment.
However, I say that if, as a company, you are made aware of the activities of the people you contracted to test your security, even if they fail to find a single exploitable vulnerability, you have valuable information and knowledge about how your monitoring systems will respond should that particular attack occur for real.
Wrong Assumptions
As an Information Security professional, it's all to easy to adopt the attitude that your clients won't notice what you're doing and certainly won't take steps to prevent you from doing it. Which in the case of small businesses, is probably true, as they are unlikely to have the incident response teams with the knowledge to prevent your attacks. This is wrong.
We should be working under the assumption that, if our client has an incident response team, or they notice something isn't quite right, they are going to respond to our actions. If that means they stop us from accessing the systems we're trying to compromise, that is a good thing.
Highlight Your Failures as Well as Theirs
If the user whose computer you're trying to attack happens to know a thing or two about security, and manages to stop you, highlight it in your reports, so that the company knows that someone in the organisation may be able to pass on their (possibly limited) knowledge to other employees.
If the IT department, having seen all the alerts you may have generated in their IDS, decides to block your IP address, meaning that you can't continue the tests, put it in your report. You may think you've failed, and you may feel that the security of your client is still questionable, but if they managed to stop your attack, whose to say they weren't already doing that against real threats?
Don't just concentrate on your successes, as this does little to actually help your clients, sure they realise that the money they're spending isn't enough, but in the current economic climate, we should be trying to show them where the money they spend is making a difference, so that they don't stop paying for the services and applications that are actually helping them.
Final Thoughts
This post may sound like I'm saying it doesn't matter if we fail to compromise a client to some level, the truth is, I'm not really saying that at all, of course it matters if we can't find at least one way into their network, as it often means we're not testing as well as we could be, and not that the environment is truly secure.
I just want to point out that, should your client actively prevent you from completing your assessment, whether it's part of established policy or not, this isn't something we should hide from them, and should realise that they may have collected valuable information of their own, in addition to what we give them in our final reports, that we may need to make them aware of.