Enabling Proper PCI Testing with Internal Penetration Tests

TL;DR:

PCI DSS v4.0.1 made internal penetration testing more complex by expanding what counts as in-scope — cloud infrastructure, SaaS applications, and build pipelines like GitHub Actions or Azure DevOps are now explicitly included, not just traditional on-prem network segments. Scoping an IPT requires understanding cardholder data flows, segmentation controls, and which network segments have unique access paths into the CDE, so that testing covers every meaningful perspective an attacker could exploit. Bishop Fox tests all segmentation controls, not just network segmentation but also authentication and authorization, because credential theft is often the most direct path into a CDE. Deliverables include an executive summary report covering both IPT and segmentation findings, plus a spreadsheet documenting tested segments, IP addresses, and open ports, with the final call on segmentation effectiveness left to the QSA.

A common question we get from clients is: “How do you approach internal penetration testing for the Payment Card Industry Data Security Standards (PCI DSS), and how does it differ from traditional testing?”

We’ve previously explained our approach for external penetration tests (EPT) but have yet to do so for internal penetration testing (IPT) and cloud penetration testing. As with our first post, the goal is to first execute exceptional security work that would be accepted by any Qualified Security Assessor (QSA).

So let's get to it, we will cover:

• What information we need to scope a PCI DSS-compliant IPT
• How we scope a PCI DSS-compliant IPT
• What does the deliverable look like
• How we cater our approach to client requirements

Scoping Documentation

We usually ask clients for the following to drive scoping that’s closely aligned with PCI DSS from the start, sourced from page 305 of the PCI DSS Requirements and Testing v4.0.1::

*12.5.2 PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes:

• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card- present, card-not-present, and e-commerce).
• Updating all data-flow diagrams per Requirement 1.2.4.
• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups.
• Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE.
• Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope.
• Identifying all connections from third-party entities with access to the CDE.
• Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope.

These documents increase our ability to adhere to the requirements of a PCI DSS penetration assessment, so we can understand the amount of systems; where the systems are at; what systems store, process, or transmit cardholder data; the flow of cardholder data through the in-scope systems; and how the different system components are connected. Gathering this information is the first step to enabling an accurate scoping process and ensure we are able to perform the required test cases during the allotted time.

In addition to the above, providing vulnerability assessment results gathered internally can augment the quality of testing by revealing other vulnerabilities not available from the chosen network locations to perform segmentation testing from. Providing the prior year's penetration testing results helps build on what was done before to extract value beyond compliance, determine if any of the issues are still relevant, and help us understand what the QSA felt was acceptable previously.

Scoping Gotchas

One of the ways that the PCI DSS has evolved is by becoming more prescriptive through explicit examples of what system components are in the context of PCI DSS scoping. The PCI DSS: Requirements and Testing Procedures, v4.0.1 captures this definition and gives three examples we will expand on:

• “System components” include network devices, servers, computing devices, virtual components, cloud components, and software.

One unique system component given is:

• Cloud infrastructure and components, both external and on premises, and including instantiations of containers or images, virtual private clouds, cloud-based identity and access management, CDEs residing on premises or in the cloud, service meshes with containerized applications, and container orchestration tools.

Due to this prescriptive change, it is possible that an IPT for segmentation testing includes* system components such as Amazon Web Services (AWS) accounts, Google Cloud projects, Azure tenants and subscriptions, and any other providers in use. This could be because systems that store, process, or transmit cardholder data run on a cloud virtual machine or container, or perhaps, orchestrate the systems that are deployed on premise.

The second notable callout that is:

• Applications, software, and software components, serverless applications, including all purchased, subscribed (for example, Software-as-a-Service), bespoke and custom software, including internal and external (for example, Internet) applications.

The nuance here is that while we would not directly attack third-party systems not owned by the client, using SaaS applications as intended must be considered part of scope. If it is possible to steal credentials of an internal user and then use those credentials to login to a SaaS application that insecurely stores cardholder data (CHD), segmentation is likely not effective.

The last notable callout as it relates to scoping involves:

• Tools, code repositories, and systems that implement software configuration management or for deployment of objects to the CDE or to systems that can impact the CDE.

This specific callout ensures that build pipelines such as GitHub Actions, AWS CodePipeline, GCP Cloud Build, Azure DevOps Pipelines, or Jenkins are also included in scope. This provides a path into the CDE if a build workflow or pipeline can be injected into or executed by an attacker.

Finalizing the Scoping Process

Now that we have reviewed needed documentation and have an accurate scope, we also want to understand how many different perspectives are required to test from. To do this, we need to understand which network segments have unique access controls into the cardholder data environment (CDE). Then we sample from the different types of networks.
One approach may involve deploying three different systems: one inside of the CDE, one in a network segment that contains shared services, and one in a network that is considered to be completely isolated from the CDE. Perhaps there are three network segments that have discrete CDEs, such as a workstation that has CHD typed into it and is then processed by a cloud-hosted application made in-house.

This process can be highly variable for clients, and we cater our internal approach given the client's environment. The approach could include a physical security appliance we ship to the client for deployment, an internal Kali virtual machine the client provides, a starting point in a compromised pod in a Kubernetes cluster, or a corporate laptop that is shipped to the testers with relaxed security controls that facilitate testing of the environment.

An important nuance to how Bishop Fox performs PCI DSS penetration testing is that we test all segmentation controls, which commonly include network segmentation and authentication / authorization segmentation. It is all too common that by stealing credentials and finding the right system, an attacker can simply log into the CDE. This is why it can be important to also test from within the CDE, to ensure that if an attacker gains CDE access, they are still unable to obtain unencrypted CHD.

Deliverables

We have a sample report available upon request which consists of two different deliverables. The first is a report that includes an executive summary with a section dedicated to IPT findings and a separate section dedicated to segmentation testing results. Some clients prefer we issue two separate reports instead; one covering exploitable internal penetration testing findings relevant to gaining unauthorized access, and one covering segmentation testing findings where controls failed to prevent unauthorized CDE access.

The other deliverable includes what we call an accompanying deliverable. Unfortunately, spreadsheets are the best way to document large lists of things, and so we do. We include the scope of what was tested on one tab, which is usually a copy and paste of Requirement 12.5.2's asset inventory. Then we have individual sheets within the workbook that documents each network segment we tested from, what our IP address was, what networks we scanned, and what IP addresses and ports were identified as being open.

Since Bishop Fox is not a PCI DSS QSA, we do not make a determination on whether or not segmentation of networks is effective. We largely rely on the QSA to make this determination given whether or not we gained unauthorized access to CHD in the context of the scope provided. Just because a port is open does not mean segmentation is ineffective; the value is in demonstrating exploitability of the service on the port by using exploit code, moving laterally, stealing credentials to login to the service, compromising build pipelines, or reusing an available session on a workstation to move into the CDE.

Conclusion

If an organization already has a QSA with clear goals and expectations in mind, this will ensure that we are properly enabled to deliver what the QSA is looking for while adding extra security value along the way.

We hope this helps those that are interested in how Bishop Fox approaches PCI DSS internal penetration testing. Please reach out with any further questions or a scoping session, as the answer to complicated systems like PCI is usually "it depends".

For a deeper breakdown of PCI DSS 4.0 and what changed in practice, see our PCI DSS 4.0 expert breakdown. If you’re working through PCI DSS scoping or preparing for an internal penetration test, our compliance and frameworks services can help align testing with both QSA expectations and real-world risk.