Open Mobile Menu


Network Segmentation

Views: 6746

Written By: Stephen Haywood July 24, 2015

There's been a lot of talk lately about network segmentation because of the new PCI DSS 3.1 standard. While the standard does not require network segmentation, it does allow a company to use network segmentation to reduce the scope of the PCI audit. However, if network segmentation is used to reduce the scope then it must be tested to ensure the segmentation is adequate. Network segmentation can be tricky and many companies struggle with properly segmenting their card holder data environments (CDE) from the rest of their network.


First, we need to understand how the PCI DSS standard defines network segmentation.

"To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE."[1]

The standard is clear the compromise of an out-of-scope system should not be able to lead to the compromise of the CDE. Where the standard is unclear is how isolated does one system need to be from another to prevent the compromise of one from leading to the compromise of the other? In many penetration tests, AppSec Consulting has taken over an entire network through a vulnerability in a single service. Accordingly, the only proper isolation is complete isolation.

Segmentation Methods

Next, we need to understand the methods available for segmenting networks. According to the PCI DSS,

"Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network."[2]

The standard describes two basic methods for segmenting a network, physical and logical. Physical separation requires creating two or more physical networks each with its own servers, switches, and routers. Logical separation, on the other hand, uses one physical network with firewalls or router facilitating communication between the logical networks.

In practice, a typical company has one physical network at each location but may have one or more logical networks. Usually, there is only one logical network and every device is allowed to communicate freely with every other device. In some cases, the servers may be on one logical network with the workstations on another. Based on what we know about the Target breach, they were using one physical and logical network, which allowed the computer used to monitor the HVAC system to communicate freely with the point-of-sale (POS) systems.[3]

Proper Segmentation

Proper network segmentation is not complex but it can be tedious work. The following method is a good place to start segmenting the CDE from the rest of the network.

  1. Identify all of the servers, workstations, and network devices that hold or process credit card data, this is the CDE.
  2. Create one or more logical networks for the CDE to use, such as one logical network for the servers and one for the workstations.
  3. Migrate each CDE device to the appropriate logical network.
  4. Place a firewall between the CDE and the other networks to prevent any communication between them. In addition, configure a VPN device with two-factor authentication to allow authorized administrators to gain access to the CDE.
  5. Place a firewall between the logical networks within the CDE and restrict access between those logical networks to only what is necessary. In other words, some workstations may only need to access specific servers on specific ports.

Over time, it may be possible to reduce the number of devices in the CDE. For example, if a user needs to access the CDE to pull weekly reports, remove that user’s workstation from the CDE and use a VPN with two-factor authentication to allow the user’s workstation to connect to the CDE and pull the weekly report. Of course, this assumes the report itself does not contain any sensitive data.

Segmentation Testing

Now that the CDE is segmented from the rest of the network, the segmentation must be tested. AppSec Consulting recommends scanning the CDE from each of the other logical networks to ensure segmentation from the CDE is working as expected. If there are a large number of non-CDE networks, a sample of the non-CDE networks can be tested as long as the sample set includes each segmentation method: firewall, router ACLs, etc.  In many cases, companies have implemented the network segmentation method described above and our scanning has found many open ports between the CDE and the non-CDE networks. Often times, it is because a firewall rule was created during testing or troubleshooting and was never removed. In fact, most networks are constantly changing, which means segmentation testing should occur at least annually and with every major change to the network.

When scanning the CDE it is best to scan all TCP and UDP ports to ensure there are no open ports but this can be very time consuming and costly. One method to reduce the number of ports to scan would be to review the firewall or router ACLs to ensure they are configured to deny all traffic from the non-CDE networks into the CDE. If the firewall or router ACLs are correctly configured then scanning the most common TCP and UDP ports would prove the deny rules are working correctly. If the firewall or router ACLs are not configured correctly, then this must be remediated before any scanning.


Network segmentation is an effective way to reduce the scope and cost of a PCI audit. However, segmentation must be implemented properly and must be tested regularly to ensure its proper implementation. While implementing network segmentation is not difficult, it can be tedious and time-consuming but the reduced risk and auditing costs are well worth the time and effort. If you need help developing a network segmentation strategy or testing your current network segmentation please contact AppSec Consulting.





Stephen Haywood

Stephen Haywood, aka AverageSecurityGuy, is a Senior Penetration Tester with AppSec Consulting with 14 years of experience in the Information Technology field working as a programmer, technical trainer, network operations manager, and information security consultant. He holds a Bachelor of Science in Math, the Certified Information Systems Security Professional (CISSP) certification, the Offensive Security Certified Expert (OSCE) certification, and the Offensive Security Certified Professional (OSCP) certification. Over the last eight years, he has helped improve the network security of many small businesses ranging in size from ten employees to hundreds of employees by offering practical, time-tested information security advice.

In his off hours, Stephen created a number of security tools including the Prometheus firewall analysis tool and a set of penetration testing scripts used by testers worldwide. In addition, Stephen has made multiple contributions to the Metasploit exploitation framework including, auxiliary, exploitation, and post exploitation modules. Finally, Stephen created and delivered high-quality security training, spoke at multiple security conferences, and self-published an introduction to penetration testing book.

read more articles by Stephen Haywood