Network segmentation is the act of dividing a computer network into subnets. When done correctly, network segmentation improves network security and performance. PCI DSS does not require network segmentation but recommends that it be implemented.
Network segmentation does not prevent an attacker from breaching your network, but the network segments are created to limit the attacker’s influence and access. Organizations with credit card information, financial information, research, and development information, and any intellectual property in their network must segment this data to be on a network other than the main network.
Therefore, networks with sensitive information such as credit card data or R&D will not be affected by this attack due to breaching your web server when appropriate segmentation is applied.
In other words, if you are processing credit card data and you can segment the portion containing credit card data, and the rest of the network does not include credit card data. Only the segment of the network you allocated falls under PCI DSS. This way, you can only apply the PCI DSS requirements for this network segment.
The reason for network segmentation tests is to determine whether the network segmentation rules applied by businesses that implement network segmentation but never really control segmentation are appropriate and valid.
As part of the penetration test, merchants and service providers must test the correct implementation and functionality of network segmentation.
The PCI DSS network segmentation is specified in requirement 11.3.4 as follows:
“If segmentation is used to differentiate CDE from other networks, perform penetration tests at least annually and after any changes in segmentation methods and isolate all out-of-scope systems from CDE to verify that segmentation methods are functional and efficient.”
For service providers, in the PCI DSS requirement 188.8.131.52, it is stated that segmentation tests should be performed at least every six months or after a significant change in segmentation.
The merchant or service provider must perform segmentation tests in the same way. The only difference between them is the frequency of the segmentation test.
What is PCI Network Segmentation Test?
Network segmentation for PCI serves many purposes. It helps to avoid congestion and bottlenecks in the overall network and separates important segments from other segments. In this way, the management of the network becomes more effortless.
Each organization should follow its segmentation process and procedures according to business requirements. For example, a large enterprise whose business includes all kinds of payments may store cardholder data (CHD) in one segment and other data in different parts.
A Cardholder Data Environment (CDE) is part of the network that stores, processes, and transmits cardholder information. Typically, a Cardholder Data Environment is within the PCI scope, and other non-scope segments are outside the scope of the PCI.
Cardholder data includes the cardholder name, card number, expiration or service code, and CVV. Cardholder data should never be compromised or disclosed.
According to PCI DSS requirement 11.3.4, the cardholder data environment (CDE) must always be secure and have limited access to other segments. Also, the CDE should only be accessible from an internal network and not access external resources in any way.
In other words, no unauthorized links should be established between in-scope PCI and out-of-scope PCI, and restricted access to in-scope PCI should be provided in any context.
Besides, businesses that store cardholder data and need compliance with PCI-DSS are required to perform segmentation testing. According to PCI, segmentation testing must be performed once a year for merchants and every six months for service providers.
Many terminologies can be confusing and need to be understood before performing segmentation tests. Understanding the language that PCI DSS defines is essential to completing tests.
There are three main scope contents in PCI DSS terminology as outlined below:
- CDE Systems – includes systems that directly process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD), or are directly connected to such systems. These systems or devices are also classified as Level 1 or Category 1.
- Connected or Affecting Systems – Systems that provide CDE services or have connections to CDE systems that can adversely affect system protection within the CDE. You can also name these systems or devices as “Shared Services,” Level 2, or Category 2.
- Out of Scope Systems – Systems that do not connect to the CDE, also known as Level 3 or Category 3 systems.
Both CDE (Category 1) and Bound (Category 2) systems are covered by PCI compliance. However, Category 3 systems are also used for network segmentation testing because the segmentation test will show that Category 3 cannot reach Category 1 or vice versa.
Generally, when it is determined that Category 3 cannot reach Category 1 in network segmentation tests, it is thought that the tests are successful. However, a PCI segmentation test targeting only Category 3 and Category 1 will not be sufficient because the tests must be made to include Category 2.
Also, PCI segmentation checks should be performed to the CDE both outside and inside the enterprise network, but mainly focus on segmentation checks from outside the CDE.
The purpose of performing segmentation tests inside and outside the CDE and other parts of the network, such as the Internet, is to support further the analysis and results of the QSA review of firewall rules and specified in the PCI DSS 1.3 requirement.
How Can I Perform PCI Network Segmentation Test?
First of all, the timing of the test is critical. PCI segmentation checks are required to be performed annually for merchants and every six months for service providers. However, if significant changes have occurred that affect network segmentation, the network segmentation test should be performed as soon as possible, usually 30 days after the significant change has been made.
Depending on the type of segmentation used to isolate less secure networks, the segmentation test methodology will also differ. Usually performs rule-based (firewall rule analysis) segmentation tests based on target rule.
There are three parts to a standard segmentation test:
- ICMP scan
- TCP port scanning
- UDP port scanning
In cases where routing restrictions prevent any packets from being delivered to the targeted segment, scanning techniques are not required. In such cases, it will be sufficient to provide evidence, such as trace paths, that packets are not routed to the correct firewall.
Documentation is generally sufficient for systems with air gaps. Some QSAs may also request ICMP, TCP, and UDP port scans from time to time to verify that there is no other access over the Internet between the two systems.
Nmap or a similar network scanning tool can be used as a test tool in segmentation tests. However, depending on how segmented the network is, testing can be a bit complex.
First, you should examine the network diagram to make the segmentation test easier. In this way, you should have detailed infrastructure information by defining PCI in-scope and non-PCI-scope segments. Ultimately, the only place you should focus on in segmentation testing is PCI coverage.
Any host and all 65535 ports (TCP and UDP) in the in-scope PCI segment should typically be scanned out of PCI scope. Full port scanning is generally considered a best practice as it is reliable.
Depending on the bandwidth of the network, a UDP scan may take longer than expected. First, to prevent scanning from taking a long time, measure the scan time by starting the scan for the 10000 most used UDP port. If the scan is not taking long, you can do a full port scan.
What are the Challenges of PCI Network Segmentation Testing?
Open | Filtered ports you may encounter.
This scenario is very typical and occurs mainly during the UDP scans performed. When Nmap cannot decide whether it is open or filtered, it marks the ports as in this state. Open | When you encounter filtered ports, verify the ports manually, and check if they are open.
For example, you can connect to that port by typing IP: port information in your browser and checking the response. If any service is running on this port and supports browsers, the port is open. Otherwise, the port is considered filtered. Likewise, you can perform the control by connecting to the port with Netcat.
Check random ports in case all ports are filtered.
There may be a chance of all packets being blocked or dropped by the firewall. You can check and verify the firewall behavior by connecting to random ports. You can connect to this port, for example, by adding IP: port information to the browser and testing the response.
If any service is running on this port and supports browsers, the port is open. Otherwise, you may consider the port filtered. In the same way, you can perform the control by connecting to the port with Netcat.
What to do if the port scan takes longer than expected?
Although fine-tuned timing controls are useful in scans, they can be confusing in some cases. Choosing the right values can take more time than the scan you’re trying to optimize. Therefore, Nmap offers a more fundamental solution with six timing models. You can define Nmap timing models with the -T option and (0-5) numbers.
If you think you are on a relatively fast and stable network, you can scan with aggressive mode rates. Finally, if you feel that you are in an incredibly fast network or compromise any speed accuracy, you can scan in crazy mode.
However, you should use the aggressive and crazy mods carefully; usually, the standard settings will do the trick.
Nmap is not the only tool available for segmentation testing. Many network tools can be used to demonstrate network segmentation. Whichever vehicle you use, you need to be careful and check the results.
There are numerous instances where packets don’t go to machines within the network segment. Just because the findings show that segmentation is in place doesn’t necessarily mean it works.
What are the PCI Network Segmentation Test Reporting Requirements?
Once you have finished testing your network segmentation, you should provide a detailed report of these tests. As a minimum, the network segmentation test report should include the following sections:
- The network segmentation test report should include a test start date, test completion date, results, and recommendations.
- Information security certificates of the person or institution performing the test and documents showing other relevant information security experiences should be available. This assures that the person or institution carrying out the test is deemed worthy of the test.
- For the work done, provide a brief frame of reference. This way, at least a high-level description of the various sections and a summary of the IP addressing within each of these sections can be easily specified in the report.
- Document and describe the significant changes that have occurred since the last segmentation test and the controls made after those changes.
- Document the methods followed and techniques used to demonstrate the segmentation of the network. Document the steps are taken in detail to prove that network segmentation is in place and is working as planned.
- Document the findings and recommendations from the network segmentation testing, particularly those that indicate that the network is not segmented as expected, resulting in a failed test. If segmentation is not available, you will need to correct these findings and retest to confirm the correction. When retesting is required, you need to keep all records and have a record of everything checked.
- The PCI segmentation test report should also contain a summary of the PCI compliance status and include the entire VLAN structure within the PCI scope.
For detailed information, you can review the PCI DSS Scope and Network Segmentation document.