What is Required for a PCI Penetration Test?

The Payment Card Industry (PCI) mandates security guidelines and standards that must be met by all organizations that interact with credit card data, often referred to as cardholder data (CHD).  Companies that deal with this data have a compliance obligation to not only secure that data but to demonstrate compliance with the PCI Data Security Standard (DSS).  Understanding those requirements and how they apply to a specific case can be challenging.

In this post, we’ll refer to version 4.0 of the PCI DSS which was released in March 2022.  Requirement 11.4 mandates regular penetration tests and outlines the details through a series of sub-requirements, 11.4.1-11.4.7.  This includes internal and external penetration testing at least every 12 months or after significant changes to the environment.  The requirements also outline segmentation validation testing that may go beyond most typical penetration tests. 

In previous versions of the standard, the term “significant change” was undefined, leaving the question to a merchant and their Qualified Security Assessor (QSA) as to what defines a “significant change” and when a new penetration test was required.  With 4.0, the standard now provides several specific examples of significant changes.  While the particulars of every situation are unique, the following list provides some guidance.

• New hardware, software, or networking equipment added to the cardholder data environment (CDE).
• Any replacement or major upgrades of hardware and software in the CDE.
• Any changes in the flow or storage of account data.
• Any changes to the boundary of the CDE and/or to the scope of the PCI DSS assessment.
• Any changes to the underlying supporting infrastructure of the CDE (including, but not limited to, changes to directory services, time servers, logging, and monitoring).
• Any changes to third party vendors/service providers (or services provided) that support the CDE or meet PCI DSS requirements on behalf of the entity.

(Reference: PCI DSS v4.0, page 26)

This list is quite broad and could create a heavy burden for growing organizations.  When changes are planned within an organization’s CDE, it may be wise to consider the annual penetration test schedule and coordinate those changes to avoid requiring additional testing. 

What’s in scope for PCI?

The latest version of the DSS standard defines the CDE as

• System components, people, and processes that store, process, and transmit cardholder data and/or sensitive authentication data, and,
• System components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD, and
• System components, people, and processes that could impact the security of the CDE.

(Reference: PCI DSS v4.0, page 9)

Several pages of additional notes detail what exactly is considered a “sSystem component”.  Additionally, requirement 12.5.2 outlines a process for determining what should be in scope that all organizations are required to review at least annually.  This process includes creating data flow diagrams of the CHD and identifying all systems and controls that impact the data.  The DSS also references an information supplement document called Guidance for PCI DSS Scoping and Network Segmentation.  This guide provides further considerations along with several examples and can be found in the Document Library at www.pcissc.org. 

Generally, the confirmation of the PCI scope is not part of a penetration test and should be determined beforehand.  However, a good tester should understand this process and be able to guide organizations that may not have fully considered some portions of their network.  Also, the tester must fully understand the boundaries of the intended scope to identify any variations or weaknesses.  For larger merchants, their QSA makes the final decision on what is or is not in scope.

Penetration Testing Methodology

DSS Requirement 11.4.1 describes the methodology used by the penetration testers.  While fairly vague, it references “industry-accepted penetration testing approaches” and requires a formally defined methodology to be used that includes exploitation and simulated attacks by manual attackers.  The strong implication is that automated scanning is not sufficient to meet the requirements.

At Secure Ideas, our methodology is based on, and similar to, other industry standard methodologies including the Penetration Testing Execution Standard, NIST SP 800-115, OWASP, and others.

Internal and External Testing

DSS Requirements 11.4.2 and 11.4.3 mandate internal and external penetration testing respectively.  This testing is not required to be performed by a PCI-certified company but must use “qualified” resources.  Additional guidance suggests that qualified personnel are chosen based on industry certifications and prior experience.  The tester(s) should also be organizationally independent, meaning that it should not be performed by individuals responsible for the development or operation of the environment.  This is generally also interpreted as implying that the tester(s) should be independent of the QSA or auditors.  Companies that perform both QSA work and penetration testing often have separate, distinct report structures.

A note in Requirement 11.4.1 defines the expectations of the internal and external testing.  Internal “means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks.”  Under previous versions of the standard, many organizations did not conduct internal testing from within the CDE.  Instead, they would perform the internal testing from the perspective of a corporate user and test the controls that prevent access to the CDE.  This new guidance confirms that the testers must test from a perspective within the CDE as well as from inside other trusted networks. 

At Secure Ideas, we recommend placing jump boxes on each trusted network, as well as within the CDE.  This allows us to test the controls and segmentation from each perspective.  From the non-CDE environments, the goal is to assess the controls that prevent access.  This usually starts with a typical domain user account that simulates a compromised user on the network.  The permissions of this account should be assigned based on the type of threat that is being simulated.  In some cases, a more privileged user account may be provided to properly assess security controls designed to limit access to different types of users. 

For testing inside the CDE, a privileged user account is generally not provided since user workstations are not usually part of that environment.  For more complex CDEs, that may be appropriate.  These questions should be included as part of the scoping process for the PCI penetration test.

The external penetration test is more straightforward.  This typically refers to all public-facing assets of the CDE.  External testing is usually performed without any user credentials, though some environments may require some level of access in order to interact with the environment.  One example of this might be a large insurance company that allows independent dealers to process credit card payments through their systems via a site-to-site VPN tunnel.  In this case, to simulate a compromised dealer, the organization might provide the penetration tester with VPN access. 

Application Penetration Testing

The DSS does not list penetration testing of custom applications as a separate requirement, but it does reference “Application-layer penetration testing” as part of the methodology outlined in 11.4.1.  That point references Requirements 6.2 through 6.4 which outline common application vulnerabilities that must be prevented and processes for “manual or automated application vulnerability assessments”.  As part of a network penetration test, all applications on the network are considered in scope for testing.  Aside from that, the objectives of an application penetration test should be discussed relevant to the integration method of the credit card processing. 

Applications that redirect a user to a third party for credit card processing may be largely out of scope for PCI while systems that accept the CHD from the user and then submit it to the processor may be fully in scope.  Understanding the nuance of how the application handles the CHD can be complicated and may take additional effort to assure that the pen test is properly scoped.

Segmentation Validation

One unique component of a PCI penetration test is the concept of segmentation validation.  Since many organizations use network segmentation to minimize the scope of the CDE, DSS Requirement 11.4.5 requires that the testers validate that the network segmentation is properly implemented.  The stated goal is to confirm that the deployed controls are “operational and effective, and isolate the CDE from all out-of-scope systems.” 

This is usually performed as a series of scans performed from each side of the segmentation controls.  For example, in a simple environment, the tester may scan the corporate network from within the CDE and the CDE systems from the corporate network.  The results of these scans are compared to the documented allowances based on business needs. 

DSS Requirements 1.2.4-1.45 outline a variety of network requirements that can be summarized as all traffic into or out of the CDE should be blocked by default and only necessary, documented traffic should be allowed.  These requirements also require documentation of the flow of CHD through the network and documentation of the allowed services, protocols, and ports. 

To properly assess this against the scans, the penetration tester(s) must be provided with this documentation.  This type of information is not typically provided in non-PCI penetration tests and is an extra step that may require additional effort.  Also, more complicated environments with several different trusted networks may significantly increase the effort as the segmentation must be validated from each one.

Two additional requirements for third-party service providers are found in 11.4.6 and 11.4.7.  The first requires that the segmentation validation must be completed every six months rather than annually.  The second requires that multi-tenant providers support their customers for external penetration testing. 

Report Expectations

The DSS does not provide many details on the format or content of the penetration test report.  However, it implies that the report should contain sufficient detail to confirm that the test met the outlined requirements.  Generally, this includes a summary of the tester’s methodology along with the findings ranked by risk.  We also include a narrative section of the report that describes the timeline of the assessment and identifies interesting things we noticed that did not rise to the level of a finding. 

For larger merchants, the report must be provided to their QSA as part of their annual compliance validation.  Smaller merchants are required to perform the testing, but may not have to share the details.  We also offer a Letter of Attestation that briefly summarizes the assessment and serves as documentation that can be provided to clients or other third parties who need to confirm the testing was performed but may not need access to the details.

Let us Help!

Secure Ideas has decades of experience with PCI testing for a wide range of organizations.  Our consultants can help you better understand your obligations and scope a penetration test that will fit your needs.