The Council’s Take On Non-Listed Encryption Solutions

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.

Advertisement

Revenue Generation Or Payment Security?

Late on Friday, November 18, the PCI Security Standards Council issued a draft Information Supplement titled ‘Assessment Guidance for Non-Listed Encryption Solutions’.  For those of you that follow my blog, these solutions would be what I refer to as end-to-end encryption (E2EE) solutions.  This is a draft document, but I would bet there will be a lot of discussion regarding it.  The good news is that it is a draft and an Information Supplement, so it is not yet official and is only offering a suggestion of how organizations should proceed.

The biggest recommendation that comes from this Information Supplement is the one that will cause the most heartburn and the most discussion.  The Council is recommending that a P2PE QSA assess a vendor’s E2EE solution and issue a non-listed encryption solution assessment (NESA).  As you read further into the document, the NESA is just a different name for a P2PE assessment.  So essentially, what the Council is recommending is a P2PE assessment without the QA review and listing by the Council of the solution on their Web site.

All I can think of is that the Council is taking this approach so that First Data, Verifone and others will be forced to get their E2EE solutions P2PE validated.  After all, if you have to go through a P2PE assessment to allow merchants to use your solution, why stop there?  Why not just get it validated and listed on the Web site?

But the next thing that is troublesome is the implication that regular QSAs are not capable of adequately assessing an E2EE solution.  That somehow the mystical P2PE QSA training process imbues some sort of encryption omnipotence on those that attend and pass the test.  If you have ever looked at the P2PE Report On Validation (ROV), I think most QSAs could easily execute it.

But I think the real reason behind this Information Supplement is revenue.  The Council is driving revenue to their bottom line with these recommendations.  There will likely have to be more P2PE QSAs and those non-listed solutions will likely end up as P2PE validated.  All of those activities generate revenue for the Council.  Revenue that is needed since the card brands have limited their funding of the Council.

Another big reason to believe this is just a revenue generator for the Council is the fact that, unlike a lot of other Information Supplements, this one was not developed by a committee of card brands, Participating Organizations, QSAs or other stakeholders.  In the 14 pages that comprise this Information Supplement, there is no page that lists any outside contributors.

So other than the Council, who could be driving this Information Supplement?

The acquiring banks?  I just completed an assessment of a merchant using an E2EE solution recommended to the merchant by their acquiring bank.  The acquiring bank is major player in the payment processing industry, so you would assume they would have pointed me to the P2PE ROV for the testing of the E2EE solution but they did not.

First Data, TrustCommerce and Verifone have never pointed me to the P2PE ROV for assessing their E2EE solutions.  So the payment processors are not demanding this sort of assessment.

One would think that the card brands would have each issued a press release announcing this draft, but they did not.

That only leaves us with a unilateral decision made by the Council that this was necessary.

But the real question is, how does this Information Supplement improve the security of the payment process?

Have there been a huge number of E2EE solutions that have been breached and this is a response?  I have not heard of any nor have I seen anything in the media indicating that E2EE solutions are a problem.

Are there “fly by night” vendors of E2EE solutions running rampant in the industry?  Not that I have encountered but it would not surprise me if there were a few.  That said, the merchants I have worked with in implementing E2EE solutions only worked with vendors recommended by their acquiring bank, payment processor or payment gateway.  In most of these cases, the solutions were from First Data and Verifone who are widely trusted in the industry.

I suppose this could be a proactive step to get ahead of things getting out of control with E2EE solutions.  But if that were the case, one would think that the card brands and acquiring banks would have been on board and pushing this effort as well as the Council and explaining that they were being proactive.  Nothing on that front either.

That leaves us with the only purpose of this Information Supplement is to generate revenue for the Council at the expense of merchants, E2EE vendors and ultimately consumers.

The P2PE standard has been a big flop in the industry because, surprise, surprise, it is doing nothing to help the industry.  If it had been adopted by the big players such as First Data and Verifone, then we would probably be in a different place.  But there is a reason those big players and others never got on board, because the standard is too cumbersome, time consuming and onerous just like the now failing PA-DSS process.

Do not get me wrong, every organization has to make money to subsidize its existence.  But I am troubled that the Council now appears to be generating requirements for the purposes of revenue generation rather than the securing of the payment process.

It appears that we have turned a corner and that it may not be a good corner to have turned.