Beware Of The 'Checklist' Penetration Tester

Part 2 in a series on spotting a novice pen tester

If your penetration tester has an overreliance on checklists, then he or she is a novice. In the hands of a novice tester, checklists are treated as both the start and the end of a test.

In the eyes of a skilled tester, a checklist defines the minimum level of testing. A common mistake made when evaluating third-party firms is to place too much weight on checklist comparisons. Sure, it's easy to compare lists, but it often leads to the omission and exclusion of much more important attributes, such as whether they can actually hack.

Consider this: You aren't feeling well, so you go to see the doctor. Your doctor follows a top 10 checklist to try and diagnose your symptoms, but none of the symptoms matched. So you're sent home with a clean bill of health because none of your problems were on the top 10 checklist. You're probably thinking that this doctor should have his medical license reviewed, but this is how many novice pen testers go about performing their assessments -- by adhering strictly to a checklist.

If you notice that the only issues being identified are the ones commonly found on a top 10 (e.g., OWASP Top 10) list, then there's a chance that those are the only ones that are being tested. Going off of a checklist can garner only so many results or findings, and oftentimes validating a finding is confused with actually performing a penetration test -- and it really is not the same. It's important to note that checklists can be helpful, but checklist-driven testing should not be the end-all, be-all when it comes to penetration testing because you can't find what you're not looking for.

It's good to ask your tester what he attempted to look for but didn't find. If you're still suspicious, then ask for evidence. A similar question to ask is: What aspects of security were strong? Carefully listen to his response because the answer should not be a statement of what you don't have (e.g., you didn't have SQL injection), but instead a statement of you do have (e.g., your input validation system is effective at stopping input-based attacks).

Part one of this series is here.