I have received a number of questions regarding my penetration testing post. All of the questions seem to concern why penetration testing is required. Penetration testing has always been a bone of contention within the network security community. So it should be expected that questions would arise regarding why it is required under the PCI DSS and why the requirement was expanded to internal testing under v1.2.
As I point out in my original post, penetration testing can leave the target compromised if testing is not conducted properly. Conducting penetration testing properly usually involves using non-production systems configured the same as the production systems. Unfortunately, a lot of organizations including some large ones do not have such environments and penetration testing must be performed against the production environment. Either way, once the penetration testing is completed the penetration tester needs to “clean up,” if possible, after the testing by removing any exploits from the devices tested. Unfortunately, a lot of tools do not allow for satisfactory clean up and the only alternative is to rebuild the device that was compromised. It is because of this that a lot of IT professionals do not like penetration testing.
Unfortunately, penetration testing is a necessary evil to ensure that an organization’s network infrastructure and servers are secure. If all you ever conduct is vulnerability scanning, how do you know that the vulnerabilities identified cannot be used to further someone’s attack against your infrastructure? And that is the problem. Without conducting a penetration test to attempt to leverage the vulnerabilities discovered, you have no way of knowing the true risk presented to your network by those vulnerabilities.
The worse problem with vulnerability scanning is that non-security professionals assume that because a vulnerability is rated medium or low, it is no big deal. They get a false sense of security because the vulnerabilities are not considered serious. Without the penetration test, there is no way to show them that the low and/or medium risk vulnerabilities can be leveraged to compromise their network and potentially gain access to their cardholder data environment. I have seen many an example where networks were compromised through supposedly low risk vulnerabilities that ultimately allowed the penetration tester a beachhead from which to launch even more sophisticated attacks from inside the network. And if you think this is unrealistic if you have properly secured your network, there are people successfully attacking just such networks.
With v1.2 of the PCI DSS, the penetration testing requirement was expanded to include the internal cardholder data environment. The reason for expanding penetration testing to the internal network was in response to the breaches that have occurred. Verizon Business Services and Trustwave had analyzed the breaches they had forensically investigated and came to the conclusion that around 70% of those breaches were the result of insider human error. And while the initial compromise did not necessarily directly involve the cardholder data environment, once the attacker was inside, there were limited barriers to compromising the cardholder data environment. As a result, the PCI SSC revised the PCI DSS requirements and mandated penetration testing as well as quarterly vulnerability testing for external and internal assets in the cardholder data environment.
PCI Guru 