Think of Home Depot’s $80-million loss after a breach exposed 56 million customers’ credit card accounts. Or Target’s $200 million in replacement expenses and credit card compromise. The figures are even more daunting for SMBs. If the security team that conducts your pentest manages to breach your enterprise system before an external hacker does, you’ll know what steps are needed to secure your most vital resources — and people’s credit card information.

What are the PCI DSS pentesting requirements?

Penetration tests related to PCI DSS are required for both network and application mechanisms of the cardholder data environment (CDE), any essential component that can affect CDE’s security and the whole CDE perimeter. This also includes testing to enable the accurate segmentation of the cardholder data environment from external systems. Along with vulnerability scanning (external and internal), pentesting meets the majority of PCI DSS’s Requirement 11 to regularly test security systems and processes. Tests must be based on the perimeter of CDE and all systems that could affect CDE’s security. Systems that are segregated from the cardholder data environment are regarded as out-of-scope for a pentest. Organizations can isolate their network to minimize the scope of the test, for instance, by implementing stern firewall rules. Taking this step can remove false positives from the initial phase of the test, as well as reduce pentesting cost (since there won’t be much to test).

What are the most critical PCI DSS pentesting requirements?

1. Requirement 11.3

This requirement says an organization should implement a formal pentesting methodology that includes internal and external pentest methods. Whether a skilled internal source conducts the pentest or the task is outsourced to a reliable third party, they’ll need to follow a predetermined methodology that defines suitable tests (such as an application layer where required) and is in compliance with an industry-accepted approach like NIST SP 800-115. Also, the methodology should be officially documented and retained by the body undergoing pentests.

2. Requirement 11.3.1

This requirement covers the need to conduct external penetration testing at least annually and after any major modification or upgrade to the company’s infrastructure or application, such as a web server integrated into the environment, a sub-network modification or an operating system upgrade. As mentioned previously, pentests can be conducted by a skilled internal resource or a qualified third-party with enterprise independence.

3. Requirement 11.3.2

These requirements mirror those detailed in 11.3.1, but require organizations to perform internal pentests instead of external. Companies need to examine the scope of work to verify that internal pentests are performed at least annually or after a major change to either an application or infrastructure. Also, it’s essential to verify tests were conducted by a qualified third party or eligible internal resource and, if applicable, were carried out with organizational independence.

4. Requirement 11.3.3

The requirement asks organizations to correct exploitable vulnerabilities discovered during pentests and carry out additional testing until the corrections are verified. Vulnerabilities here refer to the loopholes which the qualified third party or internal resource were able to exploit to gain access to something, e.g., cardholder data, company network, etc. Penetration testing results should be examined to verify the root cause of the exploit is addressed.

5. Requirement 11.3.4

According to this requirement, organizations should examine and review pentest methodology if segmentation has been used to isolate the cardholder data environment from other networks. When needed, pentesting must cover all segmentation tactics and be carried out annually by a qualified third-party or internal resource. The goal of the requirement is to verify segmentation methods are efficient and operational, and to isolate out-of-scope systems from the systems in the cardholder data environment (in-scope systems).

6. Requirement 11.3.4.1

This is an additional requirement that applies to service providers only. Service providers, in this case, refer to entities that process, transmit or store cardholder information on behalf of a third-party, or can impact the security of cardholder data with their actions. If segmentation is carried out, the scope of PCI DSS must be confirmed by conducting pentests on segmentation controls every six months (at the very least), and after any modifications or upgrades to segmentation methods/controls. Ideally, this should be implemented as often as possible to ensure the scope remains aligned and updated with changing enterprise objectives. Note: If any outputs from pentesting (e.g., script results and screenshots) include cardholder data, the pentester should ensure the data is secured as per PCI DSS guidelines.

Conclusion

Enterprises can conduct pentests by themselves with an internal resource if they’re able to prove that their methodology is sound and the pentester is independent of their team of network administrators. If these requirements aren’t met, then a relevant third party needs to be contacted to complete PCI DSS penetration testing. In case a company wants to confirm segmentation controls are effective on an annual basis (requirement 11.3.4), checks must be conducted by someone who is entirely separate from the control and implementation of the CDE. Also, organizations should strive to give as much detail as possible to the pentester. The more information the pentester has access to, the more value he/she can derive from the test. Hence, aim to equip the pentester with documentation of cardholder data or systems, or the number of expected tools you can make available. Doing so will enable pentesters to contextualize threats and analyze critical areas (where signification issues exist) thoroughly within the time-constrained testing phase.