Network Segmentation and PCI DSS Compliance

Image for post
Image for post
Photo by Thomas Willmott on Unsplash

Segmenting is good security

The spirit and intent of that article and our follow-up piece in End-to-End Encryption: The PCI Security Holy Grail provided some clarity and an approach to help organizations reduce PCI DSS compliance scope to the absolute minimum. The articles offered a soothsayer’s glimpse into what the future might hold for PCI compliance and scoping.

Much has changed since then: the ubiquitous adoption of virtualized systems; the introduction of streamlined and stripped down e-commerce solutions, including those that are shared hosted; the implementation of encrypt-at-the-swipe payment card solutions; EMV-compatible processing and more.

As technology, processes, and people have marched forward, the promise of measurable PCI scope reduction appears to have been offset by questions and concerns concerning the scoping of new technology implementations. Just as was the case when PCI DSS version 1 was released, many are still struggling to come to grips with PCI compliance scoping, even with PCI DSS version 3.2.1.

Why segment?

PCI DSS states that any device involved in the storage, processing, or transmission of cardholder data (CHD) is considered part of the segment. To keep things as simple as possible, designers should segment the network to include only those resources that are needed for transaction processing and storage. Segmentation can help reduce costs associated with your PCI assessment, and just plain offers better security — when it comes to the CDE, more restricted access is better.

PCI guidance on segmentation

To review, PCI applies to all system components included in or connected to the cardholder data environment (CDE). The CDE comprises people, processes, and technologies that store, process, or transmit CHD or sensitive authentication data.

The official definition of a system component is: any network component, server, or application included in or connected to the CDE. Some examples of system components include, but are not limited to:

  • Systems that provide security services (authentication servers), facilitate segmentation (internal firewalls) or may impact the security of (name resolution or web redirection servers) to the CDE.
  • Virtualization components (virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, hypervisors).
  • Network components (firewalls, switches, routers, wireless access points, network appliances, other security appliances).
  • Servers (web, application, database, authentication, mail, proxy, timing, DNS).
  • Applications (purchased and custom, internally and externally developed).
  • Any other component or device located within or connected to the CDE.

Added to the above is the follow-up section on what constitutes adequate logical segmentation, and it would appear that the PCI SSC has finally clarified these topics to a level that makes PCI compliance scoping a straightforward endeavor. The authors of this article agree that much progress has been made to help merchants and service providers get this right. However, there continues to be much confusion and consternation as to the implications of such new clarifications in the face of new PCI technologies and processes.

Zero Trust Networks

ZTN is a model the authors like, albeit with its complexity. A hot topic, when it’s finally released, Zero Trust Networks: Building Trusted Systems in Untrusted Networks, looks to be a valuable reference when it’s released next month.

The Zero Trust model is based on the notion that all network traffic should be considered untrusted. ZTN is broken into three concepts; no longer are there:

  1. Trusted and untrusted interfaces on security devices
  2. Trusted and untrusted networks
  3. Trusted and untrusted users

The follow-on to that is for a security architect to ensure that anything added to the network is trusted, and to secure that trusted resource adequately. It also notes that systems must be designed from the inside out, which fits quite well with the notion of PCI DSS segmentation. By proactively designing security in the CDE, segmentation can be achieved, and more threats can be prevented.

Non-listed encryption solutions

In 2009, we wrote End-to-End Encryption: The PCI Security Holy Grail. The piece offered some forward-looking conjecture and speculation about the potential scope reduction capabilities and security enhancements of end-to-end encryption of payment card-related transaction data.

In late 2012, the PCI SSC began publishing its original P2PE suite of compliance standards. The documents were formidable in their range and breadth, and have since further evolved into a comprehensive set of security and compliance requirements that address all aspects of P2PE implementation for merchants, service providers, supporting technology, and payment application vendors. Industry assertion, both at P2PE’s original inception and now, is that significant PCI scope reduction can be enjoyed by merchants and service providers who invest in P2PE certified solutions.

Industry adoption of the P2PE standards was initially quite slow, in part due to public perception of the overall complexities and costs associated with certified P2PE architectures. Additionally, some merchants and their QSA counterparts began to seriously consider cherry-picking and implementing some of the more impactful P2PE scope-reducing attributes.

An excellent example of such a P2PE-lite implementation is the use of PTS-approved point-of-interaction (POI) devices that provide encrypt-at-the-swipe capabilities, but not further embracing all the other P2PE-mandated security controls — at times, only using the specifications in a secure decryption environment to decrypt the data.

Over time, many proponents of such implementations asserted that these P2PE-lite solutions afforded the same protection and PCI scope-reduction capabilities as properly certified P2PE solutions. After a while, this PCI urban myth began to gain momentum, and solutions eventually proliferated as POI vendor and service provider marketing representatives touted their PCI scope reduction (and, in some instances, even total PCI scope elimination) of their custom-tailored solutions.

This scenario eventually created quite a bit of controversy, confusion, and disagreement among PCI professionals and their clients. Merchants and service providers implementing such solutions were insisting on getting PCI scope credit equivalent to fully certified P2PE architectures.

To deal with this, the PCI SSC issued a concerted response to this scenario, and have formally published Assessment Guidance for Non-Listed Encryption Solutions and Frequently Asked Questions: Assessment Guidance for Non-Listed Encryption Solutions.

The PCI SSC has now clearly stated that only fully certified P2PE solutions can offer the maximum PCI scope reduction for merchants and service providers. They have also said that merchants who are considering implementing, or have already implemented, non-listed encryption solutions (NLES) will need to incorporate the following to make any legitimate PCI scope reduction claims regarding their implemented POI solutions:

  1. A merchant implementing an NLES should request a scope reduction determination to be made by its acquirer.
  2. The acquirer and relevant payment application vendor should then engage with a P2PE QSA to complete a P2PE gap assessment of the NLES (E2EE) application concerning all applicable P2PE requirements.
  3. The P2PE QSA will assess the architecture and subsequently create a non-listed encryption solution assessment (NESA) report. Such a report will address determining whether or not any gaps exist between what is required for a P2PE-certified solution and the proposed NLES solution. The P2PE QSA will determine whether any discrepancies exist or whether the NLES merits any PCI scope reduction as claimed.
  4. Merchants should request to have their NLES payment application vendor provide a NEAS report at least annually, and any time the application changes.

If the preceding steps are completed before an upcoming PCI DSS assessment, the attesting QSA of record can then evaluate both the actual implementation and P2PE QSA feedback to determine if all compliance criteria have been properly met. If so, the attesting QSA of record can then choose to acknowledge any PCI DSS scope reduction claims made by the P2PE QSA, merchant, and acquirer.


Network segmentation and logical abstraction of payment application components are two compelling concepts currently applicable for reducing PCI scope within many cardholder data environments.

Proper interpretation of PCI-scoping impacts and their possible reduction is equal parts art and science. Industry consensus regarding these concepts is paramount to ensuring compliance and the consistency of security controls across the associated PCI disciplines.

About the co-author

I work in information security at Tapad. Write book reviews for the RSA blog, & a Founding member of the Cloud Security Alliance and Cybersecurity Canon.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store