Friday, 4 November 2011

You don’t want to do ‘Penetration’ Testing, probably

Here’s an interesting thing, when people talk about Security testing they usually talk in terms of Penetration testing. You can imagine the scenario, “We need to make sure our site is secure, let’s hire a security consultant to do some penetration testing”. However, they rarely mean Penetration Testing. It’s the same as people talking about software quality assurance when they mean software testing. It’s similar to Performance testing when they mean Load or Stress testing.

It’s not that we don’t understand why people use these terms in a slightly inaccurate way, hey they’re not all 24/7 live and breathe testers like us, we can give them a break regarding the terms they use.

The point is, Penetration testing is more correctly thought of as; “A sub-type of Security testing focused on exploiting vulnerabilities present in the underlying design, application code and functionality and the network the application is deployed on. This includes exploiting interconnected software systems, networks, access controls and physical security.“ to quote the Test Hats ‘Software Testing Dictionary’.

Another good definition comes from the book, ‘Backtrack 4: Assuring Security by Penetration Testing’, “The basic difference between a vulnerability assessment and penetration testing is that vulnerability assessments identify flaws… without measuring impact, while penetration testing… exploits these vulnerabilities”.

Here’s the punch line that gets missed, the active exploitation of vulnerabilities should be expected to leave systems in a compromised state and that means they’ll need to be rebuilt. You did make a back-up of the data, configuration, etc. right?

That previous bit is the bit that doesn’t get mentioned very often it appears. No, not the need for back-ups… the bit about Penetration testing of live systems leaving them in a compromised state. Truth is, Penetration testing proper is a risky business and a service that most clients don’t really want and don’t need.

Most often what’s needed and what’s being asked for is an audit and assessment of how secure the network and application is. Of more value to them is seeing how robust their ‘security posture’ is in terms of technology, configuration, patch cycles and so on. They can then take a Vulnerability Assessment or Audit report and remediate any issues on there. This is far more valuable than Penetration testing on its own.

However/But… because there’s always a but… Penetration testing has its own unique value in that if you want to truly harden your systems, your need to do Penetration testing. The fact is that Compliance Audits, Patch Audits and Vulnerability Assessments are, in the main, checks. Audits are checks of compliance against a given standard, such as PCI-DSS or your own standards, they’re fairly static. Vulnerability Assessments are more dynamic, given the threat landscape changes day to day it isn’t possible to statically define some threats in an ‘audit file’ and merrily check them.

Penetration testing is not only more dynamic the testing approach required is far different too. This is testing, not checking or auditing. But… that’s a topic for another time!

Mark

2 comments: