PCI penetration testing is a key part of PCI compliance. PCI DSS Requirement 11.4 outlines specific controls to implement for external and internal penetration tests to keep cardholder data (CHD) secure.
Is your organization seeking PCI compliance? Request a free consultation today!
How to Meet the PCI DSS Penetration Testing Requirements
Compliance with the Payment Card Industry (PCI) Data Security Standard (DSS) requires advanced cybersecurity protections for cardholder data (CHD). One of these is penetration testing, or simulating attacks on your system to assess your incident preparedness in real time.
There are two primary considerations for meeting the PCI penetration testing requirements:
- Understanding PCI DSS Requirement 11.4 and all its components
- Covering other Requirements named in 11.4 and their controls
Working with a penetration testing partner or PCI compliance advisor will help your organization scope, strategize, and implement penetration testing to achieve and maintain PCI compliance.
PCI DSS Requirement 11.4: Penetration Testing
The PCI DSS framework comprises 12 primary Requirements, grouped under prioritized security outcomes. Requirement 11, “Test Security of Systems and Networks Regularly,” includes six sub-requirements detailing what kinds of tests organizations need to run.
One such mode of assessment is penetration testing, the subject of sub-requirement 11.4.
PCI DSS Requirement 11.4 stipulates that internal and external pen tests must be conducted regularly and that all vulnerabilities they detect must be addressed. In doing so, it breaks down into five controls applicable to all organizations and two applicable to Service Providers only.
11.4.1: Penetration Test Policy and Governance
The first controls stipulated for Requirement 11.4 concern governance for your penetration testing program. Namely, there are nine stipulations your methodology needs to include:
- Ensure pen testing procedures use industry-accepted approaches
- Cover the entire perimeter CHD environment (CDE) in pen tests
- Pen test from both inside the network and outside of it
- Validate segmentation (see 11.4.5) and scope reduction controls
- Address vulnerabilities from Requirement 6.2.4 (see below)
- Conduct network-layer tests on functionality and operating systems
- Review and consider all vulnerabilities experienced in the last 12 months
- Document testing methods and all vulnerabilities identified during tests
- Retain results of penetration tests for 12 months, at minimum
These baseline controls establish the scope of your PCI penetration testing program.
Request a Consultation
11.4.2 and 11.4.3: Internal and External Penetration Tests
The next controls, 11.4.2, govern internal penetration tests. Controls for 11.4.3 apply the exact same stipulations to external penetration tests. For both kinds of tests, you’ll need to:
- Conduct penetration tests per your defined methodology (see 11.4.1)
- Conduct penetration tests at least once every 12-month period
- Penetration test after any significant change to your infrastructure
- Utilize qualified internal resources or third parties for penetration tests
- Ensure penetration testers are independent from the organization
Internal and external penetration tests differ in terms of their aims, techniques, and insights.
Internal tests simulate attacks from within the network. Real-world analogs include attacks leveraged by disgruntled current or former employees. Internal testing focuses on attackers’ movement within the system and provides insights on quarantining abilities. In external tests, the focus is on attacks that begin with little to no knowledge of your systems. They focus on perimeter defenses or points of entry. Pen tests may begin externally and continue internally.
11.4.4: Correcting Vulnerabilities Found in Pen Tests
The next controls concern corrective measures taken by an organization when a penetration test uncovers a vulnerability or weakness. Pen tests are not preventive measures in and of themselves. Instead, they are means of generating threat intelligence. This intelligence then needs to be put to use in a risk mitigation program to prevent threats from materializing.
Requirement 11.4.4 calls for pen testing to work in accordance with risk assessments, per Requirement 6.3.1 (see below). It also calls for repeated tests to verify corrections’ efficacy.
11.4.5: Pen Testing for Segmentation Controls
Next up are PCI segmentation testing controls. Namely, 11.4.5 applies when segmentation isolates the CDE from other networks (as it generally should). In these cases, you need to:
- Pen test segmentation controls once every 12 months and after changes to them
- Cover all methods and controls used for network segmentation in pen testing
- Pen test segmentation controls in accordance with your methodology (see 11.4.1)
- Confirm that segmentation controls are effective in isolating the CDE from other systems
- Confirm that systems with different security levels are separated (per 2.2.3, see below)
- Utilize qualified internal resources or third parties for penetration tests
- Ensure penetration testers are independent from the organization
Note that, if your organization does not use segmentation controls to isolate the CDE, then these stipulations may not apply. However, such a configuration is unlikely to be compliant.
11.4.6 and 11.4.7: Additional Controls for Service Providers
Requirement 11.4 also includes two sets of controls that apply to Service Providers but not Merchants as defined by the Security Standards Council (SSC). Namely, 11.4.6’s stipulations are almost identical to 11.4.5, except for more frequent testing (every six instead of every twelve). Service Providers need to conduct PCI segmentation testing more often.
And 11.4.7 applies to a smaller niche within the PCI-eligible pool: multi-tenant Service Providers. It calls for such organizations to support their clients’ and customers’ needs around PCI DSS penetration testing requirements 11.4.3 and 11.4.4 (detailed above). In practice, this means providing evidence that testing has been performed, which may alleviate the clients’ burden.
Other PCI DSS Requirements Related to Penetration Testing
PCI penetration testing guidance does not stop at Requirement 11.4. Since its controls explicitly reference other DSS Requirements and sub-requirements, it is essential to understand those other stipulations both in and of themselves and in relation to PCI penetration testing.
Namely, the two other Requirements named in 11.4 are Requirement 6 and Requirement 2.
PCI DSS Requirement 6 and Penetration Testing
Requirement 6, “Develop and Maintain Secure Systems and Software,” details specific ways to design security into software and apply patches or updates when vulnerabilities are identified.
The controls named in 11.4.1 and 11.4.4 fall under 6.2, concerning bespoke and custom software, and 6.3, which calls for vulnerabilities to be identified, classified, and ranked.
Pen tests need to account for risk factors enumerated in 6.2.4 and 6.3.1, as follows—
- 6.2.4 – Software development should account for threats including but not limited to:
- Injection attacks (SQL, LDAP, XPath, etc.)
- Data structure attacks (buffer manipulation, etc.)
- Cryptography attacks (cipher suites, etc.)
- Business logic attacks (XSS, CSRF, etc.)
- Access control attacks (identification abuse, etc.)
- “High-risk” vulnerability attacks (per 6.3.1, see below)
- 6.3.1 – Organizations should identify and manage vulnerabilities as follows:
- Identify new vulnerabilities with industry-recognized sources of intelligence, including alerts from computer emergency response teams (CERTs).
- Assign vulnerabilities a ranking based on industry intelligence and impact.
- Identify, at minimum, “high-risk” vulnerabilities critical to the environment.
- Cover vulnerabilities for bespoke, custom, or third-party software.
With respect to PCI DSS penetration testing requirements, these specifications need to inform your pen testing governance (per 11.4.1) and corrective measures taken post-test (per 11.4.4).
PCI DSS Requirement 2 and Penetration Testing
The other control referenced in 11.4 is 2.2.3, which is part of Requirement 2, “Apply Secure Configurations to All System Components.” In particular, this control falls under sub-requirement 2.2, concerning secure configuration and management of system (not network) components
This control applies to primary functions with different security levels, or different sensitivities and practices in place for safeguarding them. It calls for one of the following rules to apply:
- Only one primary function should exist on a given system component
- Multiple primary functions on the same component are isolated from each other
- All primary functions on a component are subject to the highest level of security
So, penetration testing needs to assess whether system components contain more than one primary function and, if they do, whether those functions are properly isolated or protected.
Streamline Your PCI Penetration Testing Today
PCI penetration testing requires meeting all of the specific stipulations within DSS Requirement 11, along with the portions of Requirements 6 and 2 that directly inform them. RSI Security will help your organization scope and implement a pen testing program to meet your PCI and other security needs. We are committed to serving organizations like yours, going above and beyond requirements like the ones listed above to streamline and optimize your cyberdefenses.
For further PCI penetration testing guidance, contact RSI Security today!
Download Free PCI Compliance Checklist
 |
