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.
PCI Guru 
OK so here is a big question which is not addressed in the document. What if the client doesnt want to get a NESA assessment by a P2P QSA? Can the QSA just work off common sense and determine applicable controls? The article assumes a NESA will be produced. But you can bet there will be many solution providers who DO NOT go through the NESA phase and just appoint a QSA as they always have done.
Let alone the fact that I have yet to see the NESA document as I cannot find it in the public Document Library or the private library in the Assessor Portal.
I would assume the banks and processors will allow QSAs to continue as we have been which is to conduct an assessment of the solution to assure that the E2EE solution is implemented correctly, is encrypting at the swipe/dip and then submit that evidence to the bank for their sign off that the merchant qualifies for scope reduction.
The Council has created a blog entry for this new Information Supplement, but I have not had a chance to read it yet. However I did want to pass it along.
https://blog.pcisecuritystandards.org/p2pe-assessing-non-listed-encryption-solutions
You can add Heartland E3 E2EE solution to the list of non validated P2PE too. This could get interesting to watch the card brands and the council sort this mess out, if they ever actually do.
I hadn’t spotted the new guidance and you have a very interesting take on it. At the recent European Community meeting, the PCI SSC spoke eloquently on the value of using an SRED PED; I was puzzled at the time why they didn’t mention P2PE in the same presentation and now, perhaps, you have identified why. It got me wondering, not for the first time, what exactly is the advantage of P2PE over E2EE. The SSC’s answer seemed to be, that the assessment that the decrypting service provider goes through for PCI DSS is not as rigorous as that required for P2PE. That may be true but it makes no difference to the merchant – it does not increase the risk of the data being breached in their environment. It seems reasonable to me that a merchant using E2EE should be descoped just as is one using P2PE.
The only difference between the two is the P2PE assessment process. All of the E2EE solutions I have dealt with were from recognized vendors such as Shift4, TrustCommerce, Verifone and First Data. There is no reason to assume that these E2EE solutions are any better or worse than their P2PE bretheren.
BTW SRED is just an even more secure point of interaction (POI) and is necessary to use in order to use P2PE/E2EE. An SRED device provides the on board encryption/decryption of data and manages that security on the POI.
You say “If it (P2PE) had been adopted by the big players such as First Data and VeriFone…” but as an ISA working with the VeriFone PIM for my employer I would say VeriFone have adopted it.
Some Verifone products/services have been P2PE validated. But VeriShield (their biggest E2EE solution) has never been validated. Verifone has never seen the need or the justification to validate VeriShield.