On Thursday, June 29, the PCI SSC held their quarterly Assessor update webinar. One of the more interesting discussions was on the topic of the non-listed encryption solution assessment or NESA.
For those unfamiliar with NESA, it is an attempt by the Council to have all end-to-end encryption (E2EE) solutions such as First Data’s TransArmor and Verifone’s Verishield assessed against the relevant PCI P2PE standards to ensure they are secure. The problem is that the card brands and the banks have not gotten behind the NESA approach so it has effectively stalled out much like the P2PE program has stalled out. But on the Thursday webinar we found out that it has really stalled out and the Council seems to be getting desperate to salvage it.
The goals of NESA are:
- The Council reiterated that the NESA requires that a P2PE-QSA is required to conduct the assessment using the PCI P2PE assessment programs as guidance. Essentially, the NESA is a P2PE validation without the Council’s certification and listing of the solution on the Council’s Web site.
- NESA provides a consistent approach to evaluating non-listed encryption solutions against “best practices”.
- It provides other PCI assessors, acquiring banks and merchants with information about the risk and PCI DSS responsibilities when using a non-listed encryption solution.
- It provides input to a merchant’s QSA to consider when conducting the merchant’s PCI assessment.
All of these are admirable goals of the NESA. But the question still remains, do we need the NESA?
According to the Council a lot of people in the “payments community” have been clamoring for NESA. I am not sure exactly who the Council is referring to as the “payments community” but it certainly has not been the banks or the brands. Those two constituencies are already partnered up with E2EE and P2PE solutions and have not been clamoring for anything other than to use those solutions.
The Council did bring up the organizations behind the solutions already listed as P2PE validated. That would make sense as they have a vested interest in forcing non-listed encryption solutions through the process. But as to banks, the brands and QSAs pushing this agenda? I would seriously doubt it.
Then there is the issue that the Council says that QSAs are stumped when they encounter an E2EE solution. The process of assessing E2EE solutions has been known by QSAs since E2EE solutions were rolled out years ago by the various vendors. But with the introduction of P2PE, I would bet that the Council’s QSA/ISA training does not cover how to handle E2EE solutions. And I am sure since the invention of the NESA process, they have even more reasons not to instruct QSAs on how to assess an E2EE solution. Yet I am sure that they still discuss how to assess an application that is not PA-DSS validated. That is a “shame on them” for ignoring the realities of the real world.
But the process is not that involved. When encountering an E2EE solution, the QSA needs to ensure that the E2EE solution is implemented according to its implementation guide (IG). A transaction processor/gateway or an acquiring bank may also require packet captures to ensure that the data stream is encrypted. All of that assessment and testing documentation is submitted to the acquiring bank and the bank explicitly grants the merchant scope reduction. Then the QSA can follow the requirements in SAQ P2PE for an assessment. All of which adds probably two hours to a merchant’s PCI assessment versus the costs of a full on P2PE assessment. When looking at the costs of a P2PE assessment plus the listing fees to have the solution placed on the Council’s Web site, is there any wonder a lot of E2EE solution providers have eschewed the P2PE program.
First Data and Verifone have been adamant since P2PE was introduced that they will never go through P2PE because it is not needed. Given they are partnered with most of the large processors and banks, their lack of support for P2PE means a lot and also means that until they get on board with either NESA or P2PE, both of these standards are in trouble.
But the most troubling comments occurred at the end of the Council’s brief discussion of NESA.
- NESA is NOT a program. It is only “guidance”.
- NESA may not result in scope reduction.
- There is no formal NESA documentation or template.
When the Council says that something is “guidance”, there is no mandate for anyone to do anything. This is how QSAs are to treat those Information Supplements published periodically by the Council. In this case, NESA is only a suggestion. So, until the brands and banks get behind the NESA process, there is no reason to have a NESA performed.
The next two comments go together. If there is no formal deliverable for QSAs to review, how does a QSA evaluate that any NESA process was conducted adequately? And if that is the case, of course the granting of scope reduction is not likely. After all, if a QSA is not sure about the NESA, how is the bank supposed to evaluate it let alone pay for it. And if scope reduction is not achieved, then what in the world is the point of NESA in the first place? The only purpose I can see is to give P2PE QSACs an ability to push their services on the E2EE solution vendors to make their services worth the cost incurred with the Council.
The only other benefit that I can see is an opportunity for certain P2PE-QSACs to flood us all with NESA Certificates since their PCI Compliance certificates are worthless.
But in the end, you really start to wonder what the Council was thinking when they put this process together. Time will tell, but I am guessing and hoping that NESA, like P2PE, will die a quick and quiet death.
PCI Guru 