Segmentation penetration testing for PCI compliance

Network segments are now a part of any organization or business’s infrastructure. Network segmentation is the splitting of a computer network within the infrastructure according to business requirements.

Segmentation of a network serves many purposes. It helps in avoiding congestion in the overall network and isolates crucial segments (those that have critical data) from other segments. Every organization follows their own segmentation process and procedures depending upon their business requirements.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

For example, a big organization whose business involves any kind of payment may store cardholder data (CD) in one segment and other databases in different segments. A Cardholder Data Environment (CDE) is a network segment that stores, processes and transmits cardholder data. Generally, a Cardholder Data Environment is also known as PCI (Payment Card Industry) in-scope and other remaining segments are known as PCI out-of-scope. Banks mainly have infrastructure which holds such segments.

Cardholder data includes cardholder name, card number, expiration date or service code and CVV. It should never be compromised and exposed.

The cardholder data environment (CDE) should always be secure and should have limited access from/to other segments in accordance with Payment Card Industry Data Security Standards (PCI-DSS) requirements (Req. no 11.3.4). It should only be accessible from an internal network and never be exposed externally by any means; there should not be any unauthorized link and connection between PCI in-scope and PCI out-of-scope, and limited access in every sense to and from the PCI in-scope.

In order to secure PCI in-scope (CDE), segmentation penetration testing came into practice. Businesses which hold cardholder data and require PCI-DSS compliance should get segmentation penetration testing done. Segmentation penetration testing needs to be done once every year for merchants and once every six months for merchant service providers, as per PCI.

Terms that you need to be aware of

There are various terms which might confuse us and need to be understood before performing segmentation penetration testing.

CDE in-scope: VLANs which fall under CDE in-scope are the VLANs which store, hold, process and transmit cardholder data. It should be truly isolated from the external world and should have a high level of security on each host that falls under CDE in-scope.

Non-CDE in-scope: VLANs which fall under non-CDE in-scope are the VLANs which do not store, hold, process and transmit cardholder data but having dependencies from CDE in-scope. As we already know that CDE in-scope has the limitation of being not exposed to the external world, non-CDE in-scope provides exclusive services and external resources to CDE in-scope. CDE in-scope has certain dependencies which need to be fulfilled by non-CDE in-scope. For instance, patch servers (from non-CDE in-scope) provide patches and update to CDE in-scope hosts. The antivirus server provides antivirus solutions to CDE in-scope. It truly depends on infrastructure-to-infrastructure and business requirements.

Non-CDE out-of-scope: VLANs which fall under non-CDE out-of-scope are the VLANs which do not store, hold, process and transmit cardholder data and or have any kind of dependencies from CDE in-scope. They should not be allowed to communicate with CDE in-scope in any case.

How to perform segmentation penetration testing

Tools: Nmap, Nessus or any port scanning tool.

Firstly, you should have thorough knowledge of the infrastructure by analyzing the network diagram and identify the PCI in-scope and PCI out-of-scope segments. We need to focus on PCI in-scope.

Generally, each host in a PCI in-scope segment and all 65535 ports (for TCP and UDP) should be scanned from PCI out-of-scope. It is always considered best practice to initiate the scan in batches, as it is efficient, and we get results more frequently. We should perform the scan from PCI in-scope to PCI out-of-scope and vice versa.

For instance: Batch 1: 10.10.10.1-50, Batch 2: 10.10.10.51-100, Batch 3: 10.10.10.101-150 and so on.

A UDP scan may take more time than expected, depending on the network’s bandwidth. You can start by initiating the scan for the top 10000 ports for UDP.

For example, the following command would work best for any segment:

TCP: nmap -sV -p - -T4 -v -v -oN tcpbatch1intoout.txt -oX tcpbatch1intoout.xml -Pn 10.130.1.1-50

UDP: nmap -sU -sV -T4 -v -n -Pn –top-ports 10000 -oN udpbatch1intoout.txt -oX udpbatch1intoout.xml 10.10.10.1-50

That breaks down this way:

• -sU: UDP scan
• -sV: Probe open ports to determine service/version info
• -T<0-5>: Set timing template (higher is faster)
• -v: Verbosity
• -Pn: Do not ping the host
• -oN/-oX/-oS/-oG <file>: Output scan in normal, XML, s|<rIpt kIddi3 and Grepable format, respectively, to the given filename
• -n/-R: Never do DNS resolution/always resolve

Note: All ports should be either closed or filtered while performing the scan from PCI in-scope to PCI out-of-scope and vice versa.

Challenges you may face

1. You may encounter the open|filtered state on ports as shown below:

Figure 1

The above scenario is very common and mainly occurs while performing UDP scans. Nmap labels ports to be in this state when it is unable to determine whether it is open or filtered. In such cases, verify manually and check whether it is actually open or not.

For instance, you can connect to that port by putting 10.130.31.24:3130 in your browser and checking the response. If any service is running on that port and it is reflecting on the browser, then the port is open. Otherwise, it would be considered filtered. You can also connect through netcat: $ netcat 10.130.31.24:3130.

2. Check for random ports if all the ports come out to be filtered as shown below:

Figure 2

This might be a possibility that the firewall is dropping all the packets. Check and verify by connecting to the random ports (say 443, 80, 121, 89). For instance, you can connect to that port by putting 10.130.30.3:443 in the browser and checking the response. If any service is running on that port and it is reflecting on the browser, then the port is open. Otherwise, it would be considered as filtered. You can also connect through netcat: $ netcat 10.130.30.3:443

3. What if the scan is taking more time than expected? Remove the -sV flag and change the value of -T to 5 in the nmap command. Try the following command in order to fasten the scan:

nmap -p - -T5 -v -v -oN tcpbatch1.txt -oX tcpbatch1.xml -Pn 10.130.1.1-50

Reporting

The following points need to be considered while making the report:

• It should include whole VLAN structure scope
• It should have a summary of compliance status, such as the example shown below:

Probe Source Destination VLAN Scan State Compliance Status Accessible/Not Accessible

10.130.22.1 (Out-of-Scope) 10.130.1.0/24 Out-of-Scope to CDE In-scope Non-Compliant Accessible

10.130.31.1 (NON-CDE In-Scope) 10.130.22.0/24 NON-CDE In-Scope to Out-of-Scope Non-Compliant Accessible

10.130.1.1 (CDE In-Scope) 10.130.22.0/24 CDE In-Scope to Out-of-Scope Compliant Not Accessible

Table 1

Compliant here refers to the fact that the VLAN is following PCI guidelines and has no to-and-fro external access. On the other hand, noncompliant refers to the fact that the VLAN is not following PCI guidelines and has external access to it.

It should include probe results showing open ports (if any) and filtered ports, as shown below:

Figure 3

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

Sources

• Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation, PCI Security Standards Council
• Nmap Reference Guide, nmap.org