Segmentation Testing for PCI DSS: Everything You Need to Know

Segmentation: what is it?

Nowadays, finding companies that have different network segments is usual. Often, each one of these segments is authorized to carry out specific operations, while others are precluded, and communication between the various segments is regulated by hardware and/or software protection tools.

As an example, you can think of a set of computers A authorized to browse the internet while another set B is not. In this case, it will be necessary not only to verify that browsing the Internet for computers of set B is inhibited but also that communications between group A and group B are not allowed or are subject to specific rules, in case the traffic between the two is necessary. This is because, e.g., if one of the computers in group B would be infected, it could not impact the security of computers in group A.

In the context of PCI, segmentation becomes even more essential and particular attention is given not only to communications between each segment (we will see them later) but also that segmentation is subjected to tests to verify its solidity.

Segmentation for PCI DSS:

The "Guidance for PCI DSS Scoping and Network Segmentation" (v1.1 - May 2017) defines, among other things, three fundamental elements:

• Which and how many are the network segments
• The importance of the segmentation
• How to identify which segment a system belongs to

Which and how many are the network segments?

The PCI DSS for segmentation guide identifies three segments:

• CDE Systems
• Connected-to and/or Security-Impacting Systems
• Out-of-scope Systems

The first group (CDE Systems) contains:

a system component that stores, processes, or transmits cardholder data and/or sensitive authentication data.

OR

a system component that is on the same network segment (for example, in the same subnet or VLAN as a system(s) that store, process, or transmit cardholder data and/or sensitive authentication data.

The second group (Connected-to and/or Security-Impacting Systems) contains:

A system component that is on a different network (or subnet or VLAN), but can connect to or access the CDE (e.g., via internal network connectivity).

OR

A system component that can connect to or access the CDE via another system (for example, via connection to a jump server that provides access to the CDE).

OR

A system component that can impact the configuration or security of the CDE, or how cardholder data and/or sensitive authentication data is handled (for example, a web redirection server or name resolution server).

OR

A system component that provides security services to the CDE (for example, network traffic filtering, patch distribution, or authentication management).

OR

A system component that supports PCI DSS requirements, such as time servers and audit log storage servers.

OR

A system component that provides segmentation of the CDE from out-of-scope systems and networks (for example, firewalls configured to block traffic from untrusted networks).

The third group (Out-of-scope Systems) contains:

A system component that does NOT store, process, or transmits cardholder data and/or sensitive authentication data.

AND

A system component that is NOT on the same network segment or in the same subnet or VLAN as systems that store, process, or transmit CHD.

AND

A system component that cannot connect to or access any system in the CDE.

AND

System components cannot gain access to the CDE nor impact a security control for CDE via an in-scope system.

AND

System component does not meet any criteria described for connected-to or security-impacting systems, per above.

Segmentation test, when and how:

As specified by the requirements 11.3.4 of the PCI DSS Standards (v.3.2.1 – May 2018 https://www.pcisecuritystandards.org/document_library#agreement), if segmentation is used for isolating networks, it must be verified at least annually and after any change to segmentation controls/methods. If you are a Service Provider, you must verify it at least every six months and after any change to segmentation controls/methods (requirement 11.3.4.1).

The goal of a segmentation test is to verify that:

• every interaction (logical and/or physical) between CDE Systems and Out-of-scope Systems MUST be prohibited.
• every interaction (logical and/or physical) between CDE Systems and Connected-to and/or Security-Impacting Systems and Out-of-scope System MUST be controlled and justified.
• every interaction (logical and/or physical) between Connected-to and/or Security-Impacting Systems and Out-of-scope System MUST be controlled and justified.