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 the group B would be infected, it could not impact the security of computers in the 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" (at the time the document was written, it is v1.1 - May 2017 - https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf) 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:

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 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:

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

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

System component that can impact 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

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

OR

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

OR

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:

System component that does NOT store, process, or transmit cardholder data and/or sensitive authentication data.

AND

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

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

AND

System component 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 (at the time the document was written , it is the 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.

At last, why is segmentation so important? Well, firstly because, as specified in the "Guidance for PCI DSS Scoping and Network Segmentation", segmentation can be used to help reduce the number of systems that require PCI DSS controls (basically, Out-of-scope Systems are not subject to PCI DSS controls). Secondly, because it will reduce the attack surface a malicious actor could use to damage your systems.

What could Advantio do to help you:

We could help your Company to satisfy the requirements for segmentation test, offering you professional consultancy for the scoping process and high skilled testers to verify that all the segmentation controls/methods are strong enough to protect you and your customers. Get in touch with us to get started.

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

Carlo Di Dato

Written by

I'm a vulnerability researcher and senior penetration tester, with 15 years of experience in the security field. Specialized in reverse engineering and bug hunting, during the years I discovered and published vulnerabilities in widely used software, always following the responsible disclosure model.