PCI DSS requires Internal, External Penetration testing, and Segmentation testing. But these terms are not crisply defined. In fact, “internal” is used elsewhere in the standard (for example internal vulnerability scanning) where it means something different.
Vulnerability scanning vs penetration testing
The penetration testing is a step beyond vulnerability testing that takes the knowledge of what vulnerabilities have been found, and further manual research, to exercise any possible exploit and thereby penetrate the environment. Sometimes a string of low-risk vulnerabilities can be put together to create a critical breach, which is one of the main goals of the penetration test.
What does internal vs external mean? An internal scan performs from inside the organization. This makes internal different from external because insiders (people already inside the firewall) may even have some level of administrative access and are “trusted” to have a greater level of network access and time to plan their method of attack. It also tests the risks from unwitting insider threats, such as victims of social engineering attacks like phishing.
Truvantis has a small networking device we call a “Wombat” that can be attached to your network (ideally) just outside the CDE. This device attempts to find open transmission paths, unencrypted credentials, and storage devices to attempt to gain the next level of knowledge or access. The Wombat can be replaced with an entirely virtual device in cloud-based or otherwise inaccessible environments. Contrary to popular belief, you do not normally need to test from inside the CDE.
In the external penetration test, we know no more than a random person discovering your network and attempt to penetrate it using what we can discover about it using benign discovery steps and possible misconfigurations. We also look at publicly available information to attempt to find incompletely reversed changes or depreciated assets, and illicit assets such as domain name hijacks.
Penetration testing for PCI DSS must also leverage the annual Risk Assessment that is also required, as well as talking with the penetration tester to inform them of any changes to networking or implementation. This is both to establish a common understanding of scope so that the tester can customize the test to get the most out of it and prove that the changes were implemented as envisaged. The aim is to find any exploitable methods of gaining the next level of access, all the way up to admin-level for the best chance at a real intruder covering their tracks by, for example, erasing logs or suppressing alerts.
Another of the things the penetration tester is required to take into account is any incidents that occurred during the prior year to be able to design testing to ensure that the remediation for the incident(s) was sufficiently comprehensive and successful.
A penetration test usually has to be bounded by how much time you can afford, and the standard itself only dictates a minimum bar to be met, but you want the test to be as informative as possible so planning with the tester is critical to obtaining a useful result. You should also vary the network location of the Wombat year over year so that multiple perspectives on the effectiveness of the controls are obtained.
Make sure your pen test procedure doesn’t blindly imply acceptance of the pen tester’s methodology. PCI requirement 11.3 says the QSA has to validate that you have your own methodology as a baseline for the pen tester to follow.
There is a PCI information supplement Penetration-Testing-Guidance-v1_1.pdf that goes into much greater detail.
Don’t forget that re-testing is required after the remediation if the penetration test was “successful” in finding a compromise.
Talk with your tester to make sure the test is designed to uncover any new in-scope assets as well as any incompletely de-scoped assets. Give the tester one or more standard roles within the environment to ensure that any identity and access management changes have not caused an exploitable hole. Use the risk assessment results to agree on tests needed, and ASV scans to agree on assets considered initially in scope. Make sure the QSA and pen tester agree that the scope is sufficient.
Truvantis has an experienced pen-testing staff ready and willing to advise on any of these issues. Please contact us if you have any questions, or to schedule a pen test for your environment.