Understanding P2PE, NESA, E2EE, and PCI Compliance

Posted by David Gamey on 27 Jun 2017.

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.

Merchants and Encryption Solutions

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.

The Long Road to P2PE

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.

Point-to-Point Encryption (P2PE)

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.

Benefits:

  • Designed to address complex scenarios like third party processors and decryption environments, multiple acquirers, multiple co-resident applications, loyalty and other non-financial cards, supply chain attacks, and more
  • Clear merchant assessment process that provides qualifying (i.e. eligible) merchants a small compliance footprint. This includes having a dedicated Self-Assessment Questionnaire SAQ-P2PE. It is easy for QSAs and ISAs to assess
  • Extremely tightly locked down with little wiggle room for an attacker to exploit
  • Places more of the compliance burden on the solution, application, and component providers
  • Very high assurance of encryption capability and continued operation
  • Follows the P2PE architecture
  • Well supported by PCI SSC including approved solution, component, and application listings vetted through quality assurance process
  • There are incentives available from the card brands that may provide additional benefits

Other Observations:

  • Still limited in availability
  • Lengthy for solution providers to implement and complete a successful assessment
  • May pay a premium for solutions and/or transaction cost
  • Merchant still has responsibilities including for anti-skimming

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.

Non-Listed Encryption Security Assessment (NESA)

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.

Benefits:

  • Useful for those on the path to P2PE certification to show work in progress to their merchants and their QSAs
  • Provides QSAs and ISAs with recommendations from P2PE QSAs on the potential for compliance simplification in a standardized deliverable
  • High assurance of encryption capability and continued operation
  • Shows potential to reach P2PE and its benefits
  • It may help overcome the problem that P2PE developers have had negotiating access to enable SRED from some terminal manufacturers
  • Follows the P2PE architecture
  • Requires the same quality and attention to assessment detail as P2PE
  • Provides Acquirers with a standardized way to evaluate if they will take the risk for third-party compliance simplification
  • Clear merchant assessment process that may provide qualifying (i.e. eligible) merchants a small compliance footprint.

Other Observations:

  • Unknown availability, no listings or tracking of solutions
  • Still lengthy for solution providers to implement and assess
  • May pay a premium for solutions and/or transaction cost
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Solutions don’t require SRED to be enabled.
  • Slightly more complicated for QSAs and ISAs to assess

The NESA template report summarizes the results of a non-compliant P2PE assessment. It’s divided into three main sections:

  • An informational and assessor acknowledgement section
  • A summary of how the solution deviates from P2PE

    • Deviations are currently only permitted in the actual device, application, and management of the solution. (i.e. domains 1-3)
    • All of the back end decryption environment and key injection (i.e. domains 5-6)must be fully compliant with P2PE
  • Recommendations of how the solution works with PCI DSS and where compliance can be simplified

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.

End-to-End Encryption (E2EE)

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.

Benefits:

  • Useful to merchants when P2PE and NESA solutions weren’t available or feasible.
  • Useful to acquirers with pre-existing encrypting solutions with a non-P2PE architecture (e.g. software encryption or a different back-end)
  • More beneficial if offered by an acquirer who controls and understands solution and has accepted risk
  • Potential to simplify merchant compliance

Other Observations:

  • More due diligence required on merchant side
  • Third party solution providers may be challenged to gain acquirer acceptance
  • More complicated for QSAs and ISAs to assess
  • Requires more understanding of the solution
  • What constitutes suitable validation steps
  • Solutions don’t require SRED to be enabled
  • Cannot use the P2PE Self-Assessment Questionnaire SAQ-P2PE.
  • Merchant still has responsibilities including for anti-skimming
  • Your mileage may vary

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.

Legacy Integrated POS

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.

Assessment Aids for E2EE

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

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.

PA-DSS and Payment Terminals

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.

Whitepapers

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:

  • Detailed explanation of the solution and how it operates
  • Involve actual testing of the solution and explanations of how it was tested, not just that the solution can encrypt sometimes
  • Explain how all the key objectives were met
  • Provide sufficient information that the merchant assessor can link solutions in the field to the whitepaper
  • Allow the merchant assessor to determine an appropriate level of validation
  • References including Solution provider documents and PCI guidance

Acquirer Acceptance

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.

Validation

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:

  • Evidence of PTS
  • Evidence of Solution provider DSS
  • Evidence of PA-DSS
  • Formal guidance such as P2PE Implementation Manuals (PIMs) and PA-DSS PCI Implementation Guides (IGs)
  • Acquirer Acceptance
  • Whitepapers and solution provider documentation
  • Acquirer support to gain comfort and with some validation efforts where necessary

Reporting

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.

Due Diligence and Red Flags

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

  • Our application is P2PE certified (But is the Solution? So, back to E2EE then)
  • We’re using the same solution as --- (But their gateway is in Europe, so how is yours certified?)
  • Our third party E2EE gateway and application supports scope-reduction (But does the merchant’s acquirer accept that? Does your gateway take the risk?)
  • We have a P2PE application (And? Is it certified? And the solution?)
  • Our PC based POS application provides E2EE functionality and facilitates scope reduction. (Do you even understand the first thing about PCI scope?)
  • Our E2EE solution encrypts from the terminal to the POS and our middleware re-encrypts for the bank (How does end-to-middle-to-end qualify as end-to-end?
  • In case of problems the solution can be reset to legacy by the POS? (You do know that security impacting systems are in scope too. Don’t you?)

Breaches

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?

  • In any of these, even P2PE, there could be overlooked merchant scope. A reservoir of old legacy systems or some ad-hoc flow developed by a customer service focused employee. Or shadow IT. This is why documented validated flows and accurate inventories are critical.
  • Also with any of these things, there could be compliance lapses. Usually things like this happen in processes rather than technology.
  • But what could happen in non-P2PE

    • Probably one of the most likely scenarios would be cases where the terminals are deployed before encryption is enabled and they have the capability to operate in a legacy mode.
    • Failure to use SRED is possible but less likely as many terminals this is essentially a configuration option and the core encryption for SRED and non-SRED are shared.
    • Changes in host generated receipts could result in cardholder data leakage.
    • Poorly controlled loyalty card read-back.
    • The ability to make unauthorized key changes.

Learn More:

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.