The new scoop on PCI compliance scope
Introduction — why scope?
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 amongst 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 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 shared hosting, and 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.
Why segment?
Network segmentation has long been used to increase performance and simplify management. It’s nothing more than a best practice from a PCI perspective, and not an actual PCI DSS requirement.
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. 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.
The reasons to segment are compelling, some of the main ones being:
- reduction in costs associated with your PCI assessment — the lesser the scope, the less you’ll have to pay a QSA firm
- better security — segmentation by nature means limiting access. And when it comes to the CDE, less access is better.
PCI guidance on segmentation
For years, merchants have long complained of a lack of guidance around segmentation from the PCI Security Standards Council (SSC). The SSC heard the complaints, recognized this, and a mere seven years after we wrote about scoping issues, in December 2016; published official guidance and clarification in Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation. One of the most critical efforts in this regard came to fruition and is manifested by clarifying 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 applications, internal and external developed
- any other component or device located within or connected to the CDE
Add 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 zero trust networks (ZTN), a system that segments and protects sensitive data in microperimeters. The concept of a ZTN was developed in 2010 by John Kindervag of Forrester in Build Security Into Your Network’s DNA: The Zero Trust Network Architecture.
ZTN is a concept 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.
The zero trust model is based on the notion that all network traffic should be considered untrusted. There are three concepts to ZTN are that there’s no longer a:
- trusted and an untrusted interface 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 secure that trusted resource adequately. 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 designed security in the CDE, segmentation can be achieved.
While Kindervag’s ZTN may be too forward-thinking for many organizations and require too much reengineering, its core concepts should be considered when considering PCI segmentation.
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 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 their 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. Both at P2PE’s original inception and now, industry assertions are 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 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 such 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 eventual solutions 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 amongst PCI professionals and their clients. Merchants and service providers implementing such solutions insisted 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 to make 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 their 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 applicable P2PE requirements.
- The P2PE QSA will assess the architecture and subsequently create a non-listed encryption solution assessment (NESA) report. Such a report will address determine 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 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 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 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. As acknowledged within the standards, the concept of PCI scope reduction is not only allowable but highly encouraged.
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 possible reduction is both equal parts art and science. Industry consensus regarding these concepts is paramount to ensuring compliance and security controls consistency across the associated PCI disciplines.
Note: This article was co-written with David Mundhenk, CISSP, QSA, PCIP. He is a Senior Security Consultant with the Herjavec Group. He has extensive multi-organizational experience providing a myriad of professional security services to business & government entities worldwide. David has successfully completed 200+ PCI DSS assessments, scores of PA-DSS assessments.
