It was in the early days of PCI when we wrote Lightening the PCI Load: Solutions to Reduce PCI Scope. PCI compliance scoping was then, and still is, an intensively debated topic, even among PCI Qualified Security Assessors (QSA).
The spirit and intent of that article and our follow-up piece in End-to-End Encryption: The PCI Security Holy Grail was to provide 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 ecommerce 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 with respect to 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.
Why segment?
Network segmentation has long been used to increase performance and simplify management. From a PCI perspective, it’s not an actual PCI DSS requirement, but should be considered a best practice to help prevent successful attacks.
PCI DSS states that any device that’s involved in the storage, processing, or transmission of cardholder data (CHD) is considered part of the segment. In order 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
For years, merchants have complained of lack of guidance around segmentation from the PCI Security Standards Council (SSC). The SSC heard the complaints, recognized this, and in December 2016 – a mere seven years after we wrote about scoping issues – published official guidance and clarification in Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation. One of the most important efforts in this regard came to fruition and is manifested by a clarification around what constitutes a PCI in-scope system.
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
The last few years have seen the notion of the Zero Trust Network (ZTN): a network that segments and protects sensitive data in microperimeters. The concept of a ZTN was developed in 2010 by John Kindervag (then of Forrester Research and now Palo Alto Networks Field CTO) and first covered in Build Security Into Your Network’s DNA: The Zero Trust Network Architecture.
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:
- Trusted and untrusted interfaces on security devices
- Trusted and untrusted networks
- 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 adequately secure that trusted resource. It also notes that networks 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
Besides the December network segmentation guidance, the PCI SSC also released an information supplement on assessment guidance for 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 as to 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.
A good 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 stated that merchants who are considering implementing, or have already implemented, non-listed encryption solutions (NLES) will need to incorporate the following in order to make any legitimate PCI scope reduction claims regarding their implemented POI solutions:
- A merchant implementing an NLES should request a scope reduction determination to be made by its acquirer.
- 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 with respect to all relevant P2PE requirements.
- The P2PE QSA will assess the architecture and subsequently create what is called 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 make the determination on whether any gaps exist, or whether-or-not the NLES merits any PCI scope reduction as claimed.
- Merchants should request to have their NLES payment application vendor provide an NEAS report at least annually, and any time the application changes.
If the preceding steps are completed prior to 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.
Conclusions
As the PCI SSC suite of security and compliance standards evolves, so too will the seemingly never-ending, spirited discussions regarding PCI scope and reduction. The concept of PCI scope reduction as acknowledged within the standards is not only allowable, but highly encouraged.
Network segmentation and logical abstraction of payment application components are two very powerful 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.
It’s worth noting that Palo Alto Networks has a number of resources available for secure PCI compliance, including the whitepaper “PCI Use Case: Simplify PCI Compliance With Network Segmentation.”
About the authors
David Mundhenk, CISSP, QSA, PCIP, is Senior Security Consultant with Herjavec Group. He has extensive multi-organizational experience providing a myriad of professional security services to business and government entities worldwide. David has successfully completed 200+ PCI DSS assessments and scores of PA-DSS assessments.
Ben Rothke CISSP, PCI QSA, is Senior Security Consultant with Nettitude and the author of Computer Security: 20 Things Every Employee Should Know.