T. J. Klevinsky, Scott Laliberte, Ajay Gupta

Coming cold to the subject of of penetration testing I wanted to know three things:-

 * Is it software testing?

 * Would it help me be a better penetration tester?

 * Should it be published?

Is Penetration Testing, "software testing". I think the answer is a definite yes.

There are two reasons to test software, firstly to confirm that the system or component is behaving as we expect. Secondly to generate information on which we can base decisions. Thus if I try to draw money from an ATM, I should be able to if a) I have enough money in my account and b) the ATM has not run out of money.

Supposing some malevolent person has used a vulnerability to disable the machine via its software and I do not get my money, even though both criteria are met. The ATM system has suffered a failure.. It is a moot point whether it is an act of malicisous intent which caused the failure or an error on the part the ATM company. The ATM operating company may have been slack in creating there architecture or have left an open port somewhere. The upshot is that a security vulnerability led to a failure.

The second reason of information is central to trust, without which we can not have security.

Penetration testing as described in this book, enables us to find the vulnerabilities, and report on them. Therefore meeting our criteria of software testing.

Now for the second question, would it make me a better penetration tester? This is a bit difficult as I am not likely to be involved in this line of work in the near future.

The first few chapters (see contents listing) give a gentle overview of penetration testing and define hackers and crackers. A few very large amounts are bandied about, to show how badly proper penetration based security testing is needed.

However it is only when you get to chapter 4 with its listing of 27 very wide ranging vulnerabilities, that the scale and breadth of penetration testing hits you. Even more concerning are the following chapters, which in a workmanlike way expose the holes in our systems.

All the major routes into systems are explored. Through the internet, war dialling, internal penetration, Unix, Windows, Linux, social engineering and internal attacks. The toolkit for the testing is described in simple but comprehensive terms. Again the simplicity of operation makes it even more concerning.

The authors make it clear, that at all times the penetration test must be known to someone with enough authority to stop any escalation occurring. Essential at all times is written consent to do the testing.

Last, but not least we have the question, should it be published? The argument for not publishing this book are sound. Why tell the bad guys how to break into corporate systems and make havoc?

This argument for not publishing ignores two important considerations. Firstly the bad guys already know how to break into systems. Thus they will not find anything new in this book. Secondly the secret of keeping up with the bad guys is with everyone knowing how to protect themselves.

The closest analogy I can come up with is that of crime prevention. Imagin the local police were to say "people with unlocked doors and unplugged burlar alarms are most at risk from burglars. Of course, burglars could listen to this and think "aha! Best we target unlocked houses without burglar alarms!". But then they already know that. Law abiding people would take measures to secure themselves by at least locking their doors.

If those same law abiding people were take it one step further, they may engage a security firm to test the household security and suggest further measures.

This book offers a guide to being that allegorical security firm or the householder. Forearmed with vulnerablities. Knowledge of how to mitigate the risk of them being compromised.

A lot of IT personnel and senior executives would do well to read this book. Even if it does scare them along the way.