On Monday, November 21, the PCI SSC posted a blog entry discussing their new Information Supplement titled ‘Assessment Guidance for Non-listed Encryption Solutions’. After reading their post, I had a few comments of my own.
Mike Thompson, chair of the P2PE Working Group, states that:
“We are encouraged by the significant growth of the PCI P2PE Program in the last two years and the increasing number of PCI P2PE Solutions listed on our website.”
Yes, you have gotten up to 23 listed solutions, but you are still missing First Data TransArmor, Shift 4 True P2PE and Verifone VeriShield who probably comprise the vast majority of E2EE solutions used by merchants. And most of those solutions that are validated were validated to v1.x of the standard, not the latest version. Yes, vendors are slowly moving over to v2.x but only slowly. Some of that due to the pace at which they can get through the Council’s QA process. But probably the larger reason is that the original cost of getting validated (large) and what that was actually worth in sales (small) has made them question the value of getting revalidated.
“The Council recognizes this creates a challenge for Qualified Security Assessors (QSA) in how to complete PCI DSS assessments for these merchants and that guidance is needed.”
It creates a challenge? There has been a documented and agreed upon approach in place for E2EE solutions for years. If QSAs are unaware of this approach it is only because the Council has neglected to explain that approach to them in their training. As a result, the fact that the Council now believes that guidance is needed is only the fault of the Council.
That said, the guidance the Council is providing in the Information Supplement is in the best interests of the Council because it effectively recommends the solution be P2PE assessed by a P2PE QSA.
It means a few more P2PE QSAs will be needed. There will not need to be a significant increase in P2PE QSAs because there really are not that many E2EE solutions out there that would drive the training of masses of P2PE QSAs like we have with PCI QSAs. Let alone the fact that most solution vendors will likely ignore this recommendation unless the card brands force the issue.
But better yet, if a solution vendor has to effectively go through a P2PE assessment, why not just pay the money and have the solution listed on the Council’s Web site? What better way to drive revenue for a standard that has attracted only a few providers because the assessment process is just as onerous and costly as the PA-DSS which is also in trouble.
Never mind the fact that getting through the Council’s QA process has been a tremendous nightmare. Most P2PE QSAs equate the QA process to the PA-DSS QA process which has become a huge problem for payment application providers. Since the PCI SSC is legally on the hook for validated solutions listed on their Web site, the Council is going to be extremely diligent in their review of all validated solutions.
In the end, E2EE providers are not convinced that going through the process is worth the initial and ongoing effort and costs. They are still selling their solutions without validation in higher volumes than those vendors that have gone through the P2PE validation process. And those vendors that have been through the validation process are questioning the value of the process since it has not resulted in high sales volumes.
“PCI P2PE Solutions provide the strongest protection for payment card data and simplify PCI DSS compliance efforts.”
I have to say that this is the most hilarious statement made in this post. There are a number of P2PE validated solutions that allow for the use of 168-bit triple DES (3DES) as the encryption algorithm to protect data. While 3DES is still considered “strong” by the US National Institute of Standards and Technology (NIST), they only considered it barely strong. NIST has been advising organizations for years to migrate away from using 168-bit 3DES because it is only a matter of time before it too is broken like its 56-bit and 112-bit versions. In fact they issued a new warning on 3DES late in 2015 when a researcher broke 168-bit 3DES with keys less than 6 characters in length earlier that year.
E2EE solutions being used these days are relying on the advanced encryption standard (AES) which is much stronger than 3DES and has yet to be broken in any of its variants.
“We want to make it easier for assessors, acquirers, and merchants to get the information they need to make decisions about risk and PCI DSS responsibilities when using non-listed account data encryption solutions.”
As I said earlier, there has been a process in place for years as to how to handle such solutions. It involves conducting a review of the implementation of the E2EE solution and ensuring that it is implemented properly. Then submitting the results of that assessment to the acquiring bank for their approval for scope reduction.
In the vast majority of cases, the acquiring bank or a subsidiary of the bank is also the provider of the solution, so in a lot of cases the QSA is just ensuring that the merchant implemented the solution properly and the bank signs off on the reduction in scope.
However on some occasions, the QSA must go through a bit more rigorous process to prove that the solution does in fact encrypt the data and that the data stream cannot be decrypted anywhere but at the payment processor or gateway. While this can take a bit more time, it typically is not as time consuming as the Council makes it out to be. Again, in every case, the processor or gateway has recommended the vendors involved so the process is straight forward and easily accomplished and it is only the acquiring bank that would have questions or concerns.
It is not that the P2PE approach is a bad thing. It is just that the Council over reached when they created it. The original process was messy, complex, non-modular and did not allow large merchants to continue their operations as they existed. As a result, it was not seen as necessary by the stakeholders of the standard. Without their support, there was little reason for adoption. And as it turned out, the existing E2EE solutions in the marketplace dominated it without validation.
At the end of the day, the Council is trying to force E2EE solution vendors to validate their solutions to the P2PE standard and make that standard relevant. However without the force of the card brands and banks behind it, the P2PE standard will continue to be dead on arrival.
The good news is that this is only an Information Supplement, so it only needs to be obeyed if merchants and solution vendors choose to obey it. Which based on the prevalence of E2EE solution implementations, I would expect that things will continue to go “as is”.
UPDATE: On Tuesday, December 6, 2016, the Council issued an FAQ on this subject as well as announced a Webinar for Thursday, December 15, at 11AM ET to give QSAs and ISAs an update on this topic. However in reading the FAQ, it still appears that the whole purpose of this Information Supplement is just to drive vendors to validate their solutions to P2PE since the recommendation is to have a P2PE-QSA validate the vendor’s solution to the P2PE standard(s) and then issue some sort of report for the merchants to use.
PCI Guru 
I’ve been involved with payments security since CISP days when the knuckle busters all but disappeared. I saw value in the card brands’ move to establish the PCI Security Standards Council. I’ve attended the last nine PCI Community Meetings. I met a lot of security professionals over the years and established both personal and professional relationships from all business verticals. Along the way I found an awesome security company that really “gets it” in Shift4 Corporation. I have tried to drink the PCI Kool-Aid since the beginning and over the last 10 years I have mostly agreed with the value the PCI SSC brought to the table, with the exception of their P2PE standard, which is a total abomination. Their Tokenization guidance is a close second, but that is a totally different rant of mine.
Don’t get me wrong, encryption at the swipe technologies bring great value to merchants who can then focus on what they do as merchants and not have to worry about cardholder data security. Okay, at least the merchants that actually care about cardholder data security. But in their P2PE standard the PCI SSC overtly mistrusts the decrypting entities by mandating their use of HSMs to manage cryptography. So to qualify to get on a marketing list a P2PE solution provider must have HSMs in its solution. The biggest issue I see here is merchants’ checkbox approach to a marketing list.
If merchant decision makers can’t find a particular P2PE solution on a marketing list maintained by PCI SSC, it therefore doesn’t fit in their risk and compliance box. And then the merchant does nothing because either an expensive, listed P2PE solution is not in their budget or, worse yet, the merchant would be forced to change service providers and/or processors (likely forever) and their MSP agreement has them locked into other processor arrangements.
THIS IS WHY I KEEP SAYING THE PCI SSC IS PERPETUATING MERCHANT BREACHES BY STYMYING MERCHANT ADOPTION OF ENCRYPTION AT THE SWIPE TECHNOLOGIES.
There is hope for merchants. I know of at least one non-listed P2PE solution provider that doesn’t require merchants to change processors and doesn’t charge merchant’s extra for a P2PE service. Merchants’ only cost would be for PTS/SRED validated POI devices.
At the end of the day, it’s really how securely the P2PE decrypting entity processes, stores, and transmits cardholder data after the P2PE transaction is decrypted. Of course the PCI DSS picks up from there, but ding, ding, ding! Most readers of this blog know there is no requirement in the PPCI DSS to use HSMs to manage cryptography for the storage and transmission of cardholder data. No HSM requirement in the PCI DSS! It’s time to sever the relationship between the encryption at the swipe entity and the decrypting entity in the P2PE standard. It’s all about the merchant and only the merchant since they are the entity that can qualify to use the SAQ-P2PE.
I believe the greatest impact this NESA guidance will have in the industry will be upon acquirers vying for merchant business (as you wrote in the text “… the acquiring bank or a subsidiary of the bank is also the provider of the solution…”). Merchants mindsets have been engrained with the PCI SSC’s marketing of the absolute need for P2PE, and more and more they write RFPs mandating listed P2Pe solutions. If the acquirer does not have a listed P2PE solution available, they could get dropped as a potential candidate. Having a viable E2EE solution with a corresponding NESA puts those acquirers back into the running.
As a friend of mine at a large processor recently pointed out, they are finally going to bite the bullet and get P2PE validated for that very reason.
What I don’t understand is why they think this is a QSA problem at all. The only assessment guidance for P2PE (or E2EE or whatever) is in the form of an SAQ – which the vast majority of QSAs never touch. Where is the scoping guidance for larger merchants (who complete a ROC and engage a QSA) who implement some form or POI encryption solution. Is there any official guidance at all? (I’m betraying the fact that I’ve been out of PCI for 3 years now…)
The only guidance that has ever been provided (up to this point) is when the Council told QSAs a while back at a Community Meeting to work with the merchant’s acquiring bank to come with agreed upon procedures to follow in assessing an E2EE solution. That typically involves reviewing the E2EE solution implementation guide and ensuring that it was followed to the letter. Some banks also want a Wireshark capture to ensure that the datastream is truly encrypted if the solution is not a solution from one of their approved business partners.
What does this mean: “In fact they issued a new warning on 3DES late in 2015 when a researcher broke 168-bit 3DES with keys less than 6 characters in length”. Six characters represent about 33 bits, not 168 bits.
It’s the key length issue, not the 3DES strength issue in this case. That said, NIST has constantly and consistently warned that 3DES will be DOA eventually given the availability of cloud resources to crack it. It is just a matter of time. Therefore, organizations should only use 3DES if it is their only choice.
I was first encouraged wherein Section 1.2 Scoping Criteria correctly honed in on the merchant and not the decrypting end:
· The merchant is using PCI-listed PTS POI v2 (or higher) devices for the acceptance and encryption of payment brand account data.
· The merchant never has access to account data encryption/decryption keys.
· The merchant never has access to clear-text account data transmitted outside of the device.
Then they blew it big time in a little green box on the same page “…the [non-listed P2PE] solution is expected to meet all the applicable requirements in Domains 5 and 6 as detailed in the current PCI P2PE standard.”
What do HSMs on the decrypting end have to do with the merchant’s PCI DSS scope? Zippo!!! Way to go PCI SSC! More half-assed guidance.
Under domestic standards, all Australian and New Zealand retailer POI devices have been required to implement E2EE for over a decade – see AS 2805.9. Now – two entire nations of retailers are no longer PCI compliant.
Similarly, some ATM fleet operators have their own E2EE solutions.
I estimate 30% of a nation’s ATM fleets are no longer compliant (if they ever were).
All at the press of the “submit” button by the Council.
Given this is an Information Supplement, the guidance it provides is only guidance, not a requirement. So all of those merchants and ATMs are still compliant.