We’ve discussed many of the different kinds of testing that the Payment Card Industry Data Security Standard (PCI DSS) requires previously. Among those requirements for many organizations is segmentation validation testing. Segmentation refers to the either physical or logical separation of portions of the network to prevent unnecessary communication channels. In the case of PCI, this is a technique used to reduce the scope of your compliance requirements by making sure hosts that aren’t involved in the storage, processing, or transmission of payment card data can’t talk to hosts that are involved. While segmentation removes the need to meet a lot of requirements and reduces the number of hosts in your environment that need to be compliant, it does introduce the need for segmentation validation testing, where the controls used to separate these systems are tested to validate their effectiveness.
How does segmentation validation work?
If segmentation controls are implemented, their effectiveness has to be evaluated at least every 6 months and following any “significant changes” to the organization’s network. This testing consists of manual testing and scans to ensure that any network segments that are considered out of scope “do not have connectivity to the cardholder data environment (CDE) and cannot be used to impact the security of the CDE.” As the PCI DSS Penetration Testing Guidance v1.1 points out, the entire point of this exercise is to ensure that an attacker that gains control of an out-of-scope system or network asset could not impact the security of the CDE. This testing should also include coverage of all the different kinds of segmentation technology in use, such as firewalls, VLAN ACLs, router ACLs, etc.
In more practical terms, usually this starts with port scanning using an industry-standard tool like nmap. By moving between each of the out-of-scope network segments and scanning the CDE perimeter, you can definitely prove that no out-of-scope systems have inbound connectivity to the CDE. Similarly, by scanning from the CDE to the out-of-scope network segments, any outbound connectivity can be identified (a concern due to data exfiltration or sensitive information leakage). These port scans can be supplemented by firewall or network device configuration reviews, depending on how network segmentation is implemented. Finally, if there are paths to the CDE from any segments being testing, these should then either be blocked and retested or included as part of a full network-layer penetration test to help understand the impact on the security of the CDE and PCI DSS compliance.
How is it scoped?
Many times, when you’re working with a penetration testing firm that understands PCI requirements, this activity will be included as part of your annual penetration test. The time required to perform this assessment is directly related to how many out-of-scope network segments need to be verified. These segments can be sampled at the discretion of the penetration tester, as long as a representative sample is chosen and there is full coverage of the different methods of network segmentation. If you’re not doing this as part of an annual penetration test, it will be a fraction of the cost of a full network penetration test, as the testing consists of just the initial phase of a network-level test, including host discovery and port scanning. Just like many aspects of regulatory compliance and PCI in particular, it’s extremely helpful to work with a penetration testing team that is knowledgeable about PCI requirements and is willing to help guide you through the process.