Compliance simplification, what most people call “scope reduction”, can have huge benefits in terms of saving time, effort, headaches, and money. Merchants desire ways to simplify their PCI compliance as do the card brands, acquirers, and processors. When the PCI Council announced P2PE in 2011, there was an immediate and huge demand for approved P2PE solutions. It wasn’t that merchants wanted P2PE, rather they wanted the massive compliance simplification and risk reduction that P2PE promised to provide. QSAs and ISAs hoped for clear assessment requirements to make their merchant PCI DSS assessments simpler and less ambiguous. Late in 2016, the PCI Council announced NESA (Non-listed Encryption Assessments) and there was again an immediate and huge demand for this. The problem is that the demand is based on perception not understanding.
Let’s be clear there is only one PCI approved and promoted class of solutions that provides the simplicity and clarity to simplify compliance through encryption. That is P2PE, but that isn’t the whole story. This article will look at the differences between these three types of solutions and how they can be handled under PCI. In many ways, a P2PE solution can feel like the “holy grail” of PCI, reducing the scope to only the device. In reality, P2PE solutions reduce the applicable requirements on connected-to devices to nothing.
Before we get started, the PCI Council’s guidance is clear that it is possible to simplify compliance in a justifiable and defensible fashion and this applies to several different types of encryption solutions. However, the guidance is not well understood, as it matters how you go about it. For non-P2PE, the Acquirer or Card Brands must agree to any compliance simplification. In practice, this is almost always the Acquirer's call.
When merchants invest in encryption solutions, there are a number of factors that need consideration, such as availability of P2PE, cost of the solution, projected end of life, support, local or regional factors, functionality, existing contracts and more. The challenge is that the entire landscape for encryption solutions is changing rapidly. Full transition to P2PE will take time. Merchants want to ensure they are compliant with PCI DSS, but need to balance the cost of investing in technology solutions, with maintaining their day-to-day business, ensuring that there is a positive return on investment (ROI).
Acquirers and Processors understand the demand of the market and their merchants as they strive to provide viable options for their customers. They are all acutely aware of market demand and risks. As merchants evaluate P2PE, Acquirers and processors are too preparing to evolve their offerings because of demand and because it is the right thing to do. Many are reviewing their own investment requirements to support P2PE, while others are actively pursuing P2PE solutions to be able to support the market demand.
Most people don’t appreciate how big a job it is to build a P2PE solution. It isn’t just about the initial and ongoing investment, there can be significant challenges. P2PE v1 lacked flexibility. P2PE v2 improved on that significantly. The situation is evolving and will continue to do so. While not only the P2PE standard evolves, the market itself is transforming producing a mixture of solutions. All stakeholders in this space need to understand that and learn how to deal with these changes. To illustrate this, the following charts show the current and historical state of P2PE approved solutions including the gaps between changes to the P2PE standard and emergence of the first solutions. Clearly, launching a P2PE solution is easily a one to two-year project.
Merchants and assessors want to have the best solution possible, but let us also be clear, leveraging good encryption technology today is better than waiting to leverage the best encryption technology two or three years from now.
P2PE is an official program of the PCI Standards Council and it is the only class of solution promoted by the council that permits automatic compliance simplification (aka scope reduction). However, the use of P2PE solutions is not mandatory.
If you want an analogy for P2PE, this is the DeathStar, a shiny new Battleship, or the BatMobile. All with a bumper to bumper warranty. But you still have to change the oil.
NESA is a tool created by the P2PE program to provide improved clarity and ease the PCI DSS assessment process for merchants, ISAs and QSAs when encountering solutions that are in the process of attaining P2PE validation but haven’t yet crossed the finish line. It is not promoted by the PCI SSC, nor is it a certification or approval. It is not P2PE-lite, P2PE-junior, or P2PE-anything-else. Its use is most certainly not mandated. However, in the absence of a fully validated P2PE solution, this is a good measuring stick to use.
The NESA template report summarizes the results of a non-compliant P2PE assessment. It’s divided into three main sections:
A summary of how the solution deviates from P2PE
If you want an analogy for NESA, this is the DeathStar under construction, a new Frigate during trials, or a cool armored car prototype. All without a warranty. And you still have to change the oil.
This is a catch all term for other approaches to providing encryption solutions. E2EE solutions are not standardized or necessarily consistent. Sometimes the term is totally misapplied or is misrepresented as P2PE. By nature, since these solutions do not provide automatic compliance simplification like P2PE, they require more due diligence and may be more limited than P2PE or NESA. Many of these solutions are an excellent alternative for merchants and are supported with documentation to give merchants, assessors, and implementers confidence that the solution is not simply good marketing, but that the solution provider has invested some due diligence in validating the solution, sometimes with significant rigor. The questions are how to know which solutions are good and how to safely achieve compliance footprints similar to P2PE.
For purposes of this article, a good E2EE solution resides inside a PTS approved payment terminal, doesn’t release or leak cardholder or sensitive authentication data, doesn’t share or expose keys, and protects the encryption mechanism. A good solution minimizes the attack surface and wiggle room for an attacker.
If you want an analogy for a good E2EE solution, this is a serviceable but slightly rusty Destroyer. No warranty. The oil still needs changing.
For completeness, these systems are connected, and typically see cardholder and sensitive authentication data, and are fully in-scope for all applicable PCI DSS requirements. Unfortunately, that means most PCI DSS requirements will apply. They are tricky to secure and configure and they leave a lot of wiggle room for attack. The vast majority of payment breaches happen at the POS with ever increasing malware sophistication.
Many merchants and service providers will reduce their PCI compliance scope by leveraging a PA-DSS compliant application. But it does not completely remove PCI scope, rather, it helps fast track many of the PCI requirements by transferring the responsibility to a third party.
The analogy here is a leaky long boat with all hands bailing frantically and pirates on the horizon.
When examining E2EE solutions there is a clear requirement to validate. Ultimately the merchant QSA/ISA will need to be comfortable with the solution and determine what validation steps they must perform, and which they can rely upon. They will also need to comfortable that the acquirer (or brands) support any simplification. Here we describe some of the aids and resources you may encounter.
PTS is the PCI program and standard that applies to the hardware payment terminal itself. It’s the bedrock on which P2PE, NESA, and good E2EE solutions are built. PTS approvals provide assurance that the device is resistant to tampering, supports good key management, and includes controls such as cryptographic key signing. PTS is modular and has functions that cover things like the display and various card reader components, Open Protocols (OP) (e.g. TCP/IP, WiFi, Bluetooth), and Secure Reading and Exchange of Data (SRED) which covers encryption including the use of hardware, firmware, configuration, and APIs used inside the terminal. PTS may also cover aspects of the payment application and what are referred to as firmware applications.
PTS can be relied upon with minimal validation by confirming the device approval and functionality.
It is worth nothing that confirming if a device is SRED is enabled vs capable is not straight forward. Due to this, most E2EE solutions will not have SRED enabled.
Validation options for terminal payment applications can be a bit confusing because there are many of them. Payment applications in terminals need to be covered by some kind of PCI validation. It can be P2PE, PA-DSS, DSS, or even PTS (firmware). A couple of points are worth noting. First, PA-DSS is not required for P2PE applications as that is part of P2PE. And secondly, while PA-DSS is valuable to DSS it does not by itself provide any validation or guarantee that it can simplify compliance or reduce a merchant compliance footprint. That requires additional validation.
PA-DSS can be relied upon for the device DSS. The PCI Implementation Guide (IG) must be followed by the merchant. It can prove invaluable in gaining understanding of the solution. The IG will help in determining what additional validation is needed to support compliance simplification.
Many solution providers have whitepapers about their E2EE solution and make claims about the ability to simplify compliance. It is important to remember that these aren’t official attestations and cannot be relied upon by themselves. As there is no standard for these, the quality and completeness can vary significantly. However, good whitepapers can be invaluable in E2EE validation. The good ones will have characteristics such as:
Acquirers are ultimately responsible for monitoring and accepting merchant risk. They can accept compliance simplification for E2EE solutions. They may or may not accept the risk of a breach.
A merchant and assessor equipped with good validation aids should be able to determine an appropriate series of validation steps. They should consider all available aids, such as:
SAQ merchants can’t use SAQ-P2PE. Instead they will need to use the most appropriate form (e.g. SAQ B-IP, SAQ-D, etc.) that they are eligible for and justify any non-applicability.
With any encryption solution, due diligence is important. It’s easy enough for even an honest and diligent salesperson to get it wrong. You will need formal documentation. And you’ll need to confirm if your Acquirer supports you. This is clearest with P2PE.
Over the years we’ve heard a lot of things that raised some obvious red flags, here are a few paraphrased examples (and our reaction):
No one wants a breach. And no-one wants to have a breach because they oversimplified their compliance. So what can go wrong in these scenarios?
But what could happen in non-P2PE
If you are at a critical point in your technology or solution design decision process and would like a second opinion, give Control Gap a call, we are happy to help.
Original Publication: 2017-06-27
Updated PCI FAQ & Learn More links: 2023-06-16
David Gamey : Nov 29, 2016 10:07:00 PM
Earlier this month the PCI Security Standards Council published a new document as part of the Point-to-Point Encryption (P2PE) program. This initial...
David Gamey : Dec 2, 2016 10:07:00 PM
Anyone who relies on the PCI FAQ site for guidance may have noticed some changes in the last few months. In fact if you bookmarked some of the links...
David Gamey : Nov 26, 2016 10:07:00 PM
While you may have heard of carbon footprints and ecological footprints, you might not be aware that there is such thing as a PCI Compliance...
David Gamey