PCI DSS Network Segmentation Testing

What is Network Segmentation?

Network segmentation refers to the practice of splitting a computer network into subnetworks, each being a network segment or network layer. This procedure enhances efficiency and security, creating a series of isolated networks within a larger network system.

Two fundamental reasons behind promoting network segmentation are enhancing performance and increasing security. By segmenting the network, data packet traffic is reduced as packets are confined to their respective segments, thereby streamlining data flow and reducing network congestion.

From a security perspective, network segmentation is akin to a bulkhead in a ship. If one segment experiences a security breach, the impact is confined to that particular section, helping to prevent the spread of breaches or malware to other parts of the network. It also enables easier monitoring and management of different sections of the network, offering administrators better control over data flow and security.

Network Segmentation in PCI DSS

In the context of the Payment Card Industry Data Security Standard (PCI DSS), network segmentation plays a crucial role in safeguarding sensitive cardholder data. Network segmentation for PCI DSS, also known as ‘cardholder data environment’ (CDE) segmentation, involves isolating the systems that process, store, or transmit cardholder data from those that do not. This focused isolation helps in narrowing the scope of PCI DSS assessments, consequently reducing the cost and complexity of compliance.

Organizations are not required by the PCI DSS to implement network segmentation. However, without it, the entire network is in scope for PCI DSS, which can be overwhelming and cost-prohibitive for larger organizations. Therefore, implementing network segmentation is often seen as a strategic move to streamline compliance efforts and allocate resources adequately.

PCI DSS terminology includes various terms related to network segmentation testing. Network segmentation is a crucial aspect of PCI DSS compliance, as it helps to isolate sensitive data and reduce the scope of the cardholder data environment. Some key terms in this context include:

  1. CDE Systems: The Cardholder Data Environment (CDE) systems are those which directly process, store, or transmit cardholder data or sensitive authentication data (SAD). These systems have a direct impact on the security of cardholder data, thus requiring stringent security measures in accordance with PCI DSS requirements.

    • Point-of-Sale (POS) Systems: These are devices or systems where customers conduct transactions. POS terminals, whether physical units in brick-and-mortar stores or virtual software in e-commerce, directly handle cardholder data.

    • Payment Processing Systems: These are systems that handle the backend processing of card transactions. They communicate directly with financial institutions and card networks to authorize and settle transactions.

    • Data Storage and Backup Systems: Any systems that store cardholder data, whether on a temporary or permanent basis, fall within the CDE. This includes databases, backup servers, and even cloud storage if they’re used for cardholder data.

    • Network Devices in CDE: Devices like routers, switches, firewalls that are within or connect directly to the CDE are part of it. They may not store cardholder data, but they provide pathways for it to move within and out of the CDE.

  2. Connect-to-CDE Systems: These are systems that have the capability to connect to the CDE. While these systems do not directly handle cardholder data, their potential to access the CDE means they could be exploited as a gateway for malicious activity. For this reason, they also fall within the scope of PCI DSS compliance.

    • Remote Access and Administrative Systems: These are systems utilized by staff to remotely access the CDE for administrative or maintenance purposes. Examples include VPNs, remote desktop applications, and administrative interfaces.

    • Authentication Servers: These systems validate the identities of users trying to access the CDE. This includes systems like Active Directory servers and two-factor authentication systems.

    • Configuration and Patch Management Systems: These systems are utilized to manage software updates and configuration changes within the CDE, such as system center configuration manager (SCCM) or WSUS servers.

  3. Out-of-Scope Systems: Out-of-scope systems are those that do not fall into either of the above categories. These systems neither handle cardholder data directly nor have the ability to connect to the CDE. Consequently, these systems are not subject to PCI DSS-compliance requirements. However, it is essential to ensure these systems are adequately isolated from the CDE to maintain their out-of-scope status.

    • Personal Computers: These are systems primarily used by employees for tasks unrelated to the CDE. As long as these systems don’t have the ability to access, process, store, or transmit sensitive authentication data, and are adequately isolated from CDE, they are considered out-of-scope.

    • Non-Connected IoT Devices: Objects like smart coffee makers or smart refrigerators that are Internet-enabled but do not have any interaction with the CDE fall into the out-of-scope category.

    • Stand-Alone Systems: These are systems that are physically isolated, and have no network connectivity to the CDE or any system that connects with the CDE. An example could be a stand-alone POS terminal that processes card payments but whose data is never transmitted or stored, and is only printed on a physical receipt for the customer.

PCI DSS Network Segmentation Example
PCI DSS Network Segmentation Example

Testing Methods for PCI Network Segmentation Testing

Testing the efficacy of network segmentation in the context of PCI DSS involves performing a series of checks to ensure that systems within the cardholder data environment (CDE) are adequately isolated from those outside it. This process typically involves three main steps: scoping, verification, and documentation.


The first step is to define the scope of the PCI DSS environment. This involves identifying all systems that process, store, or transmit cardholder data, as well as any systems connected to these. The scope may also include systems that can affect the security of the CDE, even if they do not directly processing credit card data.


The verification process begins with the utilization of network mapping tools like NMAP. This open-source tool allows security professionals to discover hosts and services on a computer network. It assists in creating a “map” of the network, providing a clearer picture of what systems are in place and how they interact.

Using NMAP, the network can be scanned to detect operating systems, hostnames, device types, and more. This information is critical in understanding potential vulnerabilities within the network and designing effective penetration tests. For instance, knowing the operating system of a network device can provide insights into potential OS-specific vulnerabilities that might be exploited.

Once the network map is complete, the next step is performing penetration testing and vulnerability scanning. This involves attempting to exploit the potential vulnerabilities identified during the network mapping phase. Penetration testing can confirm whether these vulnerabilities could allow undesirable traffic between the CDE and out-of-scope systems.


Finally, all findings from the testing process should be thoroughly documented. This includes recording the methodologies used, the results of the tests, and any recommended actions or remediations. This documentation serves not only as a record of the testing process, but also as a roadmap for addressing any identified weaknesses or vulnerabilities.

Segmentation Test Report

Upon completion of segmentation testing, the report should include a comprehensive account of all actions taken, the findings, and next steps.

The first area to document is a detailed overview of all the tests conducted. This includes the specifics of what was tested, when it was tested, and who performed the tests. The network areas that were scanned and the testing methodologies used should be clearly indicated. The tools employed, such as NMAP, should be listed, along with the reasons for their selection.

The second part of the documentation should be dedicated to the findings of the tests. It should account for all vulnerabilities identified, their severity, and the potential risks they pose to the network. Including clear technical specifics on each vulnerability can provide valuable insights for those looking to understand the threats to the system.

The final and one of the most critical components of the report is the recommended remediation actions. These recommendations are derived from the vulnerabilities identified and should provide clear, actionable steps to mitigate the risks. This could involve patching vulnerable software, closing unnecessary ports, or changing security settings.

The report might also benefit from an executive summary, offering a high-level overview of the testing process, its key findings, and recommended actions for non-technical stakeholders. This ensures that the critical information from the segmentation tests is accessible and understandable to all relevant parties.

Who Should Perform Network Segmentation Testing

Network segmentation testing should ideally be performed by a team of experienced cybersecurity professionals. This team may be an internal group within the organization, or external consultants brought in specifically for this purpose. The key requirement is that they have a deep understanding of network architectures, potential vulnerabilities, and the testing processes required to identify and address these vulnerabilities.

These professionals may have a range of job titles, but often include roles such as Network Engineers, IT Security Consultants, or Cybersecurity Analysts. They should have expertise in using tools like NMAP and have experience in conducting penetration tests, as well as in documenting their findings in a clear, actionable manner.

Challenges of PCI Segmentation Testing

Complex Network Architectures

Complex network architectures pose significant challenges to PCI Segmentation Testing due to their intricate designs and extensive interconnections. With multiple layers of hardware, software, and data flows, it becomes increasingly difficult to establish clear boundaries and segregate sensitive data.

This complexity can hide unexpected or overlooked paths for data flow, potentially exposing cardholder data to other segments of the network not compliant with PCI DSS. Furthermore, changes in one part of the network can inadvertently affect another, leading to potential vulnerabilities. Consequently, maintaining PCI compliance in such an environment requires a careful, thorough, and continuous testing process.

Dynamic Cloud Environments

Ensuring consistent segregation becomes exceedingly challenging in dynamic cloud environments. These environments are designed to be flexible, scalable, and rapidly changeable to fit the needs of businesses. However, this dynamic nature also means that internal network segments can frequently change or shift, making it difficult to maintain a clear demarcation of data. It’s like trying to draw lines in the sand while the tide is coming in.

Moreover, with the adoption of multi-tenancy and shared resources in cloud computing, ensuring the isolation of cardholder data becomes even more complex. Unintentional misconfigurations or oversights in shared environments can accidentally expose sensitive data to non-compliant segments. Therefore, keeping up with these changes and continually testing the boundaries to confirm PCI compliance becomes an ongoing challenge in dynamic cloud environments.

Legacy Systems Integration

Legacy systems integration presents a unique set of challenges for PCI Segmentation Testing due to their inherent design and architecture. These systems, often built around proprietary technologies, lack the flexibility and adaptability of modern systems. They were designed for a different era of data management, and thus, are not inherently built with today’s security and compliance standards, like PCI DSS, in mind.

Additionally, legacy systems may not be compatible with modern testing tools and methodologies, making it difficult to accurately assess and manage data flows for compliance purposes. Valuable cardholder data might traverse through these older systems, potentially exposing it to network segments that are not compliant. Furthermore, the endeavor to update or modify these systems to meet compliance requirements might not only be technically challenging but also resource-intensive. And despite all the efforts, full compliance might still remain elusive due to the outdated nature of these platforms.

Securinc’s Penetration Testing Expertise

In light of the complexities in achieving PCI compliance, especially when dealing with shared cloud environments and legacy systems, Securinc can help perform penetration tests for you and provide a comprehensive examination of your network’s security.

Our team of seasoned professionals understands the unique challenges posed by shared cloud environments and legacy systems, dedicating their skills to ensuring your cardholder data remains isolated and secured. Securinc’s services extend beyond identifying security vulnerabilities. We assist in formulating and implementing robust strategies to rectify identified weaknesses and ensure continuous monitoring for optimal data protection.

By partnering with Securinc, businesses can effectively manage their PCI DSS requirements, safe in the knowledge that their cardholder data is kept secure and compliant amid the evolving landscape of digital transactions.

Our Latest Update

News and Insights

× Whatsapp Us!