ETA Expert Insights: P2PE for Fintech, Payment Technology, and Innovation

By Sam Pfanstiel, Viking Cloud
Member of the PCI Working Group • ETA Risk, Fraud & Security Committee

This year is the 10th anniversary of the first Payment Card Industry (PCI) Point-to-Point Encryption (P2PE) standard. Although a few of the specific requirements have changed (mercifully, merchants no longer need to weigh their devices periodically to check for the presence of skimmers!), the purpose of the program remains the same: to securely encrypt cardholder data at the point of interaction (POI), thereby devaluing the data in the eyes of attackers and reducing the validation effort for merchants using P2PE-validated solutions.

In this post, we explore the evolution of the program, how P2PE affects merchants, and how payment technology providers can use P2PE to better (protect and) serve their customers.

OVERVIEW AND HISTORY
In a generic sense, terminal-based encryption has been around for decades. At its most fundamental level, this architecture involves encryption of sensitive card data, such as the primary account number or track data, within a tamper-resistant terminal device, so that data can be passed to a gateway or processor before it is unencrypted. Theoretically, if properly implemented, the approach would reduce the need for other merchant security controls, such as anti-malware, firewalls, or logging — but only if the device protections and encryption are strong enough to trust that the underlying data is safe from compromise. This is where the P2PE standard from the PCI Security Standards Council (PCI SSC) came in.

For such an architecture to be considered secure enough to allow merchants to forego validation of other PCI Data Security Standard (PCI DSS) controls, it is first important to be able to trust that the device has not been substituted and cannot be manipulated (either by altering or attacking the device, application, or encryption configuration). Thus, the P2PE standard outlines the best practices regarding POI device supply chain, key loading, configuration, and application security.

Similarly, it is important that no unauthorized parties can get access to keys that could be used to decrypt the encrypted account data, and that the algorithm and key strength are strong enough to prevent attacks on the underlying cryptography. For this reason, the P2PE standard identifies acceptable cryptographic architectures as well as incorporated minimum key sizes, key storage protections, and distribution methods.

Under the P2PE program, technology providers and processors may submit their solution for validation by a P2PE assessor. In the past, there have been solution providers that have claimed to offer P2PE, but whose solutions had not been validated. A validated P2PE solution may be assessed under the five the domains covered by P2PE standards — either directly or using component providers.  The five domains of P2PE are as follows:

• Domain 1: Encryption Device and Application Management
• Domain 2: Application Security
• Domain 3: P2PE Solution Management
• Domain 4: Decryption Environment
• Domain 5: P2PE Cryptographic Key Operations and Device Management

Solutions that meet all applicable P2PE controls may then be published on the PCI website at PCISecurityStandards.org/P2PE, where they are often referred to as listed solutions.

Entities that provide only a limited role in delivering this service (for instance, only writing applications that run on POI devices, or only managing and injecting encryption keys into POI devices) can be validated and listed as application or component providers. There are currently 11 entity types that fall into these three categories, each filling a unique role. See Table 1.

For legacy solutions that either predated the P2PE standard or have been architected outside of the prescriptive requirements of the P2PE standard, these solutions are considered non-listed.  The reasons such solutions may fail to meet certain controls may be due to specific use cases that impose business constraints; thus, it is likely that some improved security exists. However, because the PCI P2PE standard and program was designed to provide a specific path to compliance, the compliance impacts of non-listed solutions are not predetermined but must be determined by the acquirer, payment facilitator, or card brands responsible for compliance — often with the aid of a qualified security assessor (QSA) or QSA (P2PE) to aid in reviewing and validating scope.

It is important to note that only a currently validated listed solution can be confirmed to have met these requirements. The listed solution thus provides the best protection for merchants, while also ensuring that they receive the benefit of reduced PCI scope and eligibility for the SAQ (self-assessment questionnaire) P2PE, as well as other compliance benefits discussed below.

IMPACT ON SECURITY AND COMPLIANCE STANDARDS
There are many good reasons for service providers to participate in the P2PE program — among them productizing on-demand encryption services, optimizing terminal device supply chains, or streamlining secure payment flows. The most important reason, however, is to protect the cardholder data by securing the transaction environment, thereby reducing the risk of account data compromises that subject our industry to fraud and ultimately result in loss of inventory and increased transaction costs.

Devaluing the Data
The first security benefit of P2PE is that it dissuades bad actors from access attempts on the protected payment environments. One common model used to better understand the mind of a cybersecurity adversary — and ultimately a great way to stop them — is the Cyber Kill Chain, which describes the sequence most attackers follow: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Actions on Objectives. When performing the first step, reconnaissance, an attacker will determine if the card data is better defended using cryptography and, if so, will redirect their efforts elsewhere. It simply isn’t economical to try a brute-force attack on encrypted card data. Thus, if an attacker does gain a foothold via malware or insider threat and is able to capture encrypted account data, they will likely look for other ways to monetize their efforts rather than exfiltration of account data, since it is far too costly and difficult to find the right way to decrypt it.

Reduced Attack Surface
Most retail environments have many points of entry into the payments environment, including but not limited to every checkout point-of-sale (POS) terminal, back-office systems, network devices, and third-party service providers. However, with P2PE, where encryption protects the card data from the point of acceptance all the way to the point of processing, there are significantly fewer places that an attacker can legitimately gain a foothold, either by attacking the payment terminal devices themselves (point of encryption) or by attacking the account data after it reaches the processor’s environment (point of decryption). This is why it is so important to focus both on checking the integrity of any devices for skimmers and using only currently validated solutions for processing.

PCI SSC Programs and Guidance
The third area where we see tangible benefits are related to the PCI standards and their programs and guidance that impacts an entity’s compliance to the card brands requirements. The PCI SSC oversees the P2PE program and publishes both the P2PE and PCI DSS standards. It also provides guidance for how merchants may meet these compliance requirements, as described below. (It is worth noting that the PCI SSC does not handle matters of merchant compliance, however, which must be directed to the acquirer or card brands for final resolution.)

SAQ P2PE
Merchants who use a validated P2PE solution and that are small enough to perform a self-assessment may be eligible to complete a much smaller SAQ P2PE. This SAQ contains only 33 questions (90% fewer questions than the SAQ D) and, if the merchant does not handle credit cards on paper, the number of requirements is even smaller! This reduction in requirements means that those smaller merchants that meet all eligibility requirements for P2PE can reduce the costs of implementing security controls that are not applicable to their payments environment as well as costs they would have incurred if they had to perform an annual assessment.

ROC
For large merchants that must complete a Report on Compliance (ROC) to attest to their PCI DSS compliance, the positive impacts of using a validated P2PE solution are still substantial. Although the exact controls must be determined by their QSA, for merchants who have properly implemented P2PE the general impact to the payment environment scope and control applicability is like that of the SAQ P2PE.

Scope Reduction
Scope reduction is a general concept that applies when certain systems are no longer deemed to fall within the cardholder data environment. The most common form of scope reduction is segmentation, whereby firewalls and physical access controls can provide proven isolation to ensure that certain systems or processes cannot affect credit card security. Similarly, P2PE can also provide scope reduction, because of its isolated systems that transmit only encrypted card data (such as a POS workstation that uses a P2PE-validated terminal can be considered as out of scope).

NESA Guidance
While not part of the P2PE program itself, the PCI SSC has produced guidance on the use of non-listed encryption solutions. For solution providers that undergo a gap assessment to the P2PE standard, their P2PE assessor may issue guidance that instructs the merchant’s assessor as to which PCI DSS controls may be considered not applicable. In general, the closer an organization is to full P2PE compliance, the more PCI DSS controls may be considered not applicable for their merchants. Note, however, that this guidance is still subject to interpretation by the merchant’s QSA and acceptance by the merchant’s acquirer.

Acquirer Programs
Today, many acquirers offer their own P2PE solutions or non-validated encryption solutions that provide a similar level of security. Since acquirers are ultimately responsible for confirming that their merchants meet the various card brand security programs, many acquirers allow merchants that use their solutions to complete a smaller self-assessment. They may also provide guidance to their customers’ assessors as to which requirements should be considered in and out of scope. Merchants using non-listed solutions provided by their acquirer should always reach out for available guidance in performing their assessments.

Card Brand Programs
In addition to the programs offered by acquirers, the card brands have various programs that may provide merchants a waiver from having to perform their annual assessment. Among these programs are the Visa Technology Innovation Program (TIP) and the Mastercard Cybersecurity Incentive Program (CSIP) (p. 22) (formerly the Mastercard Compliance Validation Exemption Program). Under each of these card brand programs, a merchant that implements validated P2PE and meets all other eligibility requirements may forego their annual attestation. A merchant should consult with their acquirer or card brand to determine eligibility to these programs and potential benefits.

PAYMENT TECHNOLOGY PROVIDERS
For ETA member payment technology providers that work directly with card-present merchants or work with acquiring and gateway partners who do, there are many roles that may be played as part of the federated P2PE ecosystem. The P2PE standard is currently in its third major version release (3.0) and now identifies 11 entity types that may undergo validation. Ten of these entity types can receive their own listing on the PCI website, thus forming the directory of services for solution providers bringing such a service to market. Currently there are over 340 such entities and products that have been validated and listed, which shows the growing support for the P2PE program.

Below is a summary of each type, along with a description of what types of organizations may find value in being assessed to each.

Table 1:  Summary of PCI P2PE entity types

VALIDATION
For organizations that provide POI device services or support the management of encryption keys or cryptographic devices, validation as a P2PE solution, component, or application provider is both an incredible opportunity and a differentiator. But be aware, P2PE validation will undoubtedly require commitment from both the product and compliance teams to meet and maintain the necessary controls required under the program.

It is recommended that such entities contact a seasoned P2PE assessor company in their region that can work with them to properly determine their scope and role in the P2PE ecosystem as well as identify any gaps between their current implementations and the prescriptive requirements found in the P2PE standard. The P2PE Assessor company would ultimately be the ones to perform the assessment.

If a solution/implementation is found to be compliant, the report, which is called a P2PE Report on Validation, and supporting documentation is submitted to the PCI SSC for review, approval, and ultimately for listing, usually within 30-60 days of submission.

It is worth noting that merchants that wish to receive the benefits of P2PE may engage solution providers only directly, and it is the solution provider that must engage the application and component providers for listing in conjunction with their solutions. For this reason, application and component providers should reach out to solution providers to discuss how their services can align with their existing offering to deliver valuable services to the merchant community.

CONCLUSION
For card-present merchants and payment technology providers, moving to P2PE represents an important and invaluable transition. The stability and security provided by P2PE helps the payments ecosystem devalue credit card data and reduces its attack surface, thereby reducing potential fraud and the high costs associated with applying and monitoring security protections to certain systems. Increased participation by vendors that provide card-present payments technology, or that support cryptographic processes for entities that do, will help provide more options and improved flexibility in the delivery of secure transactions.