Posted by Ed Welsh, Director, Security & Compliance on February 1, 2010 2:14 PM
PCI DSS requirement 11.3.1 indicates the need for annual network penetration testing, which includes an "internal" penetration test by an experienced security tester. GSI has always supported this activity by working with whomever our clients ask to perform the testing. This requirement can be met by using experienced internal staff or third-party professionals (see 11.3 Supplement), and we have seen both. Even though the selection of who does the testing is easy to make, the location in the network from which to perform the internal testing is another matter.
The environments GSI manages at PCI levels of security are particularly isolated with strong two-factor controls required for all administrative entry points. These environments are characterized by strict firewall change-control procedures and system hardening with accompanying audits. Another feature of these secure environments is the complete lack of desktop-level systems. Environments meant to house highly secure single-function payment processing systems do not require the abundance of services seen in systems that support desktop access for users. There are not any personal directory shares, email clients, productivity packages, or Internet user communication technologies present on these systems.
All of this culminates into a distinct lack of what the PCI DSS would determine to be an "internal" network.
So where does that leave us regarding internal penetration testing for requirement 11.3?
There are two scenarios that can play out:
One is for the client tester to be placed directly into the cardholder environment. This type of test assumes the attacker has compromised at least one system in the environment. The result of this test reflects how much information could be accessed post-compromise. Many QSAs will accept this as a proper internal test of the environment even though it is not strictly adhering to the intent of 11.3. In my opinion, it is not a valid test of risk exposure for the environment, because it completely disregards the security protections it is meant to test.
The second scenario is for the client's QSA to give them a "pass" on the internal penetration test requirement with the knowledge that, by definition, an internal penetration test is not possible. There is not an internal network to test from. We are starting to see more of this as QSAs better understand how the environments are managed at GSI. This decision is not arrived at lightly and even when the QSA gives a pass for an internal penetration test, it is only after the environment meets specific criteria. We must prove that administrative access is strictly protected by two-factor authentication and VPN connectivity. We also must show that there are not any desktop networks directly connected to access shares or services. At GSI, this is easily done with configuration diagrams and firewall configurations.
I have stated in a previous article that the PCI standards will inevitably lead to risk-based implementations. The ability for highly protected environments to forgo an internal penetration test is an excellent example of how a QSA can take the risk approach into their own hands and utilize the PCI standard in a flexible way to meet the intent, save clients money, and concentrate security where needed -- all at the same time.