Natasja Bolton, Senior Acquirer Support, investigates
We previously wrote about the release of PCI P2PE Version 2 and its impact for acquirers and their merchants. In this follow-up article we explore an issue that has come to Sysnet’s attention: that many terminal solution providers and point-of-sale (POS) vendors appear to be actively avoiding P2PE Validation for their solutions.
These providers implement ‘end-to-end’ encryption with their solutions and may even be advising their merchant and acquiring customers that these solutions are ‘just as secure’ as a P2PE solution.
In light of recent questions on whether this can be the case and what this may mean for merchant compliance, Acquirer Support Manager Natasja Bolton interviews Oleg Aksyonenko, Sysnet’s resident QSA (P2PE) and PA-QSA (P2PE) to find out more.
Natasja: “Why is it that POS vendors and terminal providers don’t want to go for P2PE Validation for their solutions?”
Oleg: “There are many views that prevent or distract vendors and providers from pursuing P2PE Solution validation. Some think that P2PE as a standard has become irrelevant or redundant, or that it is too difficult and complex to achieve and unnecessary given the security they believe they can build in to their solutions.
“There is also the perception that as a standard P2PE is overly onerous but that’s not really true. I agree that P2PE v1.1 was tough but that is no longer the case in P2PE v2 – it has fundamental changes in it.
“Many vendors also believe that P2PE Validation isn’t possible given the nature of their solution. For example, their solution is only one element that needs integration with other components to make a complete merchant solution.”
Natasja: “Is it the case then that P2PE Validation really isn’t as difficult as it is perceived to be?”
Oleg: “Yes, I believe so. Many POS vendors and terminal providers’ perceptions of P2PE are based on its first iteration. P2PE suffers because of how hard v1 was to achieve. The P2PE standard now is very different from the first release of the standard. P2PE v2 Solution validation is not as difficult to achieve and maintain as it was with v1.1.
“This is because P2PE V2 changed the responsibility for or removed many of the requirements that were the most difficult for solution providers to implement and maintain, including the POI (Point of Interaction) chain of custody, POI device inventory and lifecycle tracking requirements.
P2PE v1.1 also included requirements that many considered almost impossible to meet (such as requirement 5E-2.6.1 of P2PE v1.1), the PCI SSC recognised this and removed those requirements in v2.
“The major improvements to my mind, though, are the ability to separately assess and list P2PE Validated components (that deliver specific P2PE domains) and the accompanying restructuring of the P2PE Standard to allow for the building of compliant P2PE solutions using those P2PE solution components.
With P2PE v1.1 validation was only possible for an entire P2PE Solution – the provider therefore had to do everything themselves. Often they were unable or reluctant to take on that overall solution provider role.”
Natasja: “So what are P2PE Component Providers?”
Oleg: “The P2PE v2 standard allows for the assessment and listing of providers validated as capable of delivering specific elements of a P2PE Solution. P2PE Component Provider services can include:
- Encryption-management services,
- Decryption-management services,
- Key-Injection facility services,
- Certification Authority/Registration Authority services.”
Natasja: “How is the availability of P2PE Component Providers an advantage?”
Oleg: “Well, the principle of independent assessment of the fulfilment of specific P2PE requirements already existed in P2PE v1.1 but only with P2PE Applications (the software or other files, with access to clear-text account data, loaded onto PCI-approved POI devices) used as part of a P2PE solution. This principle has been expanded to include independent assessment of providers of P2PE Components.”
“The advantage of this approach is that P2PE Component Providers, and P2PE Application vendors, need only undergo compliance assessment once; those compliant components can be used in multiple, different P2PE Solutions and do not need to be re-assessed as part of each P2PE Solution.
“This makes overall P2PE Solution Validation much easier. The Solution Provider can delegate responsibility for, and also validation of, a significant sub-set of the P2PE Requirements to P2PE Component Providers.
“This, in turn, has a significant impact on an organisation’s ability to develop a P2PE Validated Solution. Previously P2PE Solution projects were bulky, complex and involved many disparate parties with differing priorities.
Bringing all of that together to deliver a Validated P2PE Solution took significant time and effort. It was apparent this was a problem as there were lengthy delays in P2PE v1.1 Validated Solutions appearing on the PCI SSC’s listing.
“The ability to build a P2PE Solution with already assessed and compliant components and applications has made the development of a P2PE Validated Solution much easier and more achievable, and in sensible timescales.
Organisations wishing to develop P2PE Solutions, such as acquirers who want to offer their own P2PE solutions to merchants, will find P2PE v2 makes delivery of a validated solution much simpler.
They are able to delegate responsibility for fulfilment of P2PE requirements, split the delivery of the P2PE solution into manageable phases, and build a compliant solution by integrating individual P2PE components, separately assessed by the responsible component providers.
“If organisations maximise their use of P2PE Component Providers then the assessment of the overall P2PE Solution will cover only Domain 3 (and Domain 4 for merchants acting as their own P2PE solution providers): the solution provider’s management of the overall solution and of the various third parties involved in its delivery and operation; and the preparation and distribution of the P2PE Instruction Manual (PIM).”
Oleg’s last point is illustrated with the table below, showing how many parties can come together to deliver a P2PE Validated Solution, with the Solution Provider responsible for the overall management:
|1: Encryption Device and Application Management||The secure management of the PCI-approved POI devices and the resident software.||Encryption-management services Component Provider|
|2: Application Security||The secure development of payment applications designed to have access to clear-text account data intended solely for installation on PCI-approved POI devices.||P2PE Application Vendor|
|3: P2PE Solution Management||Overall management of the P2PE solution by the solution provider, including third-party relationships, incident response, and the P2PE Instruction Manual (PIM).||Solution Provider|
|4: Merchant-managed Solutions|
(this domain is not applicable to third-party solution providers)
|Separate duties and functions between merchant encryption and decryption environments.||Merchant as a solution provider|
|5: Decryption Environment||The secure management of the environment that receives encrypted account data and decrypts it.||Decryption-management services Component Provider|
|6: P2PE Cryptographic Key Operations and Device Management (Includes Annexes)||Establish and administer key-management operations for account-data encryption POI devices and decryption HSMs.|
|Encryption-management or decryption-management services Component Provider|
Key Injection Facility or Certificate Authority/Registration Authority services Component Provider
*adapted from: ‘P2PE Solution Requirements and Testing Procedures’, version 2.0, pages 2 and 9
It seems therefore that the development and validation of P2PE Solutions is easier and more straightforward than vendors and terminal providers may be telling you.
Editor’s note: since this interview we have become aware that in some cases the apparent ‘avoidance’ of P2PE Solution validation by some terminal solution providers is due to the fact that the ‘component provider’ of the Decryption Environment is the acquiring bank, whose systems are not yet able to support P2PE.
Natasja: “We often hear that “P2PE-like” solutions are easier to develop and manage. Or that they are as secure as P2PE Validated Solutions. Is this really the case?”
Oleg: “I don’t think that it is.
“P2PE validation provides assurance that there is a ‘chain of trust’ for the entire solution.
That is there is trust in and independent assurance of each element that makes up the solution: from the secure encryption environment deployed to the merchant (the PCI PTS device, its use of SRED to encrypt the card data on capture and the P2PE Application facilitating the transaction), the cryptographic operations (including key injection and key management), to the security of the decryption environment (including the secure decryption devices: HSMs).
With P2PE v2 solution providers can build secure solutions composed of proven trusted components; these solutions are validated as secure from end to end.
“However, with “P2PE-like” solutions (or end-to end encryption solutions, such as semi-integrated point-of-sale solutions that encrypt card data at the payment terminal) how do you know that all components and third parties involved are PCI DSS compliant? How is a user of those solutions to know that there aren’t weaknesses in the solution that could result in a data breach?
There has been no independent assessment to provide assurance of the end to end security of the overall solution.
“The PCI SSC and the card brands are both very clear that merchants can assess their PCI DSS compliance against the SAQ P2PE (or on-site assessment of those P2PE requirements) only when using validated P2PE Solutions.
Indeed Visa Europe, in their 2014 update to the Technology Innovation Programme (TIP), stated that ‘solutions that have not been validated to the P2PE standard don’t offer the same degree of assurance as validated solutions’. TIP requires a solution risk assessment as ‘some POI encryption solutions have been poorly implemented’.
“Merchants, and the acquirers to whom they must validate PCI DSS compliance, need proof of the trust and security of the end-end encryption solution they are deploying. If that cannot be provided through P2PE Validation of that solution, then that ‘proof’ must be gathered as part of the merchant’s own compliance assessment.”
Natasja: “But, doesn’t that negate the whole reason that vendors are pushing their “P2PE-like” or end-to end encryption solutions?”
Oleg: “We have seen that many POS vendors and terminal providers promote their secure end-to-end encryption solutions to merchants as an easier route to compliance due to PCI DSS scope reduction and the ‘removal’ of cardholder data from the merchant environment. I think they are over-stating or over-simplifying the situation.
“When a merchant chooses to implement an end-to-end encryption solution, such as a semi-integrated point-of-sale solution, they should be considering the PCI DSS compliance of all parties involved in the delivery and operation of that solution and assessing fulfilment of all applicable requirements.
For example, they should be considering whether the decryption environment operated by a PCI DSS compliant service provider. They should be asking whether the security of the key injection facility has been assured through PCI compliance assessment. But this is not easy for merchants to understand or a simple exercise for them to achieve.
Most will simply follow the guidance of the solution provider in completing their PCI DSS compliance assessment of the deployed solution in their environment.
“Sysnet has seen examples of “P2PE-like” solutions that are entirely built of secure components, including PCI PTS devices with SRED enabled, PA-DSS validated applications, operated from environments managed by PCI DSS compliant service providers and with guidance equivalent to the PIM provided to the merchants using the solutions.
However, for whatever reason, the provider has not undertaken P2PE assessment of the overall solution so they cannot demonstrate that ‘chain of trust’. As there is assurance in the individual components this can make PCI DSS compliance assessment for merchants somewhat easier but they still can’t assess compliance against the P2PE SAQ requirements.
“We have also seen end-to-end encryption solutions that: don’t rely on the SRED hardware environment to encrypt card data at capture by the POI device; or, aren’t deployed and operated by PCI DSS compliant service providers; or, where PCI DSS compliance for the critical services and components, such as key injection facilities or key management cannot be proven.
Indeed, even if the solution provider end-to-end encryption solutions such as these was PCI DSS compliant, I don’t believe that provides adequate assurance for their key injection facilities.
Cryptographic operations and key management requirements in PCI DSS focus only on protection of stored cardholder data and not on the protection of cryptographic key operations in relation to POI devices and HSMs.
“My recommendation to terminal solution providers, point-of-sale (POS) vendors and component providers involved in the delivery and management of these “P2PE-like” solutions is to take another look at the P2PE Program.
I can’t deny that there are some really ‘good’ and secure “P2PE-like” solutions in the market but I do think that if these vendors and providers are able to build such solutions, then it really is just a small additional step for them to achieve P2PE validation for their solution.
This final step will eliminate any remaining doubts (from merchants’, acquirers’ and their QSAs’ perspectives) regarding the solution’s security and the compliance assessment scope.”
Sysnet’s Risk & Assurance team of cybersecurity consultants includes specialists like Oleg. Our team of P2PE Assessors, Payment Application Assessors and QSAs is qualified and ready to assist you and your customers with all aspects of PCI including P2PE assessments, PA-DSS payment application assessments and well as PCI DSS compliance.
If you are a merchant that requires technical or PCI DSS help, please click here