6 Common Vulnerability and Penetration Testing Oversights

Looking at the average network firewall penetration testing tools, it’s easy to see why so many organizations are still getting hit with incidents and breaches. There’s no way you can possibly secure things that you don’t find (or miss) during vulnerability and penetration testing, and some of the vulnerability and penetration testing results that I have seen over the years are often not worth the paper its printed on much less the high price associated with undertaking this testing. So, what’s missing? Well, it’s nothing super technical or all that sexy. It’s just a lot of little oversights that you just can’t afford to overlook.

Here are the top oversights of vulnerability penetration testing that I see in my work as a security consultant:

1. Work is performed by someone who might not be qualified. People entering this field must start somewhere, but when high-end firms let their junior engineers drive entire projects with little to no peer review or management (the biggest part of the problem), there are bound to be some oversights and omissions. You wouldn’t compromise on the experience of a surgeon, building contractor, or attorney. Don’t let the lack of experience, knowledge or checks and balances lead to your next big breach.
2. Testing with network security controls enabled. Sure, I know it’s a “penetration” test, but reality shows us that most network security controls such as intrusion prevention systems and web application firewalls, as well as SIEM systems are imperfect at best. You can leave blocking and throttling enabled for vulnerability scans all you want but real-world attacks launched by criminal hackers who have nothing but time on their hands will no doubt get through them, eventually. Why not make the best use of your resources and efforts and whitelist source IPs for vulnerability scans? It’s the only defensible way to show that reasonable and proper security testing was performed. If you must leave your security controls enabled, enable them at the end of the project and see which of the vulnerabilities discovered in the first round of testing are discoverable and/or exploitable at the end and highlight those differences in your report.

3. Stopping the testing once a single vulnerability is detected. This is why I don’t like calling this type of work “penetration testing”. If the goal is to cease all testing and analysis once a vulnerability has been flagged then you haven’t done due diligence in terms of fully understanding your overall security risks. If that’s what you need then a full security assessment that includes everything will need to be performed.

4. Assuming that traditional vulnerability scanning and penetration testing is enough. I’ve embarrassed myself a few times over the years when it comes to finding the flaws that matter. When performing traditional vulnerability and penetration testing, I may have uncovered X and Y but I missed Z. Not unlike performing a source code analysis when doing a truly thorough web application security assessment, running a firewall rulebase analysis along with your penetration testing efforts will, in most cases, take your insight and outcomes to a whole new level. Given that there’s only a finite period of time to perform vulnerability and penetration testing in the traditional sense, looking at firewall rules and how they may be contributing to security vulnerabilities is a great way to augment your testing with insight that can show you additional avenues of attack.

5. Failing to wrap-up the project with a well-written report containing information that all parties can read, understand, and digest. In many cases, penetration test deliverables are merely vulnerability scanner tool reports – often hundreds of pages. Unless scans are all you paid for (which should cost much less, by the way) that’s inexcusable. Often, at best, these scanner reports are combined with either a summary document that’s of little value or an in-depth report that only the security expert can understand.

6. Not following through. I have witnessed security assessments being performed – time and again – including my own – where substantial efforts and resources went into the actual testing and deliverables but then they fell short in terms of addressing the problems found. The report becomes shelfware or there are excuses such as the vendors won’t support these changes or fix their poorly-written code or there’s a plan to decommission that system in the near future (which in reality rarely seems to actually happen).

When it comes to vulnerability and penetration testing, don’t be that person – or organization – that merely goes through the motions and doesn’t follow through. The path of least resistance is tempting but it’s a great way to get yourself and your business into a real bind when security flaws are overlooked and not properly addressed.