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 
So I have seen a NESA but have you you accepted an “annual self-assessment” attestation / addendum to a NESA?
see page 6 Assessment Guidance for Non-Listed Encryption Solutions
“Providers of non-listed encryption solutions should perform an annual self-assessment of their solution. The self-assessment confirms that the solution has not changed; and the solution provider should attest to zero changes in its current NESA documentation.
any thoughts on these annual NESA addendums / self-attestations?
NESA was a solution seeking a problem in my very humble opinion.
The fact that a provider can perform a “self assessment” should speak volumes about the reliability of the NESA process.
There is nothing “lite” about the costs of NESA certification. We discovered it costs as much time and money for a P2PE-QSA to conduct a NESA against our existing E2EE solution as it would cost them to perform a P2PE assessment against its replacement solution. So, that was a no-brainer. As others have said, “What’s the point?”.
I agree with what you say about NESA. Whatever the Council may say, it clearly is P2PE-lite, and not all that ‘lite’ at that. Why bother? Having said that, I was a bit puzzled by your description of a ‘two-hour’ E2EE process. I’d love for it to be that easy but who has approved that process? Prior to NESA I’m only aware of the guidance in VISA’s TIP and this requires an assessment by a P2PE for the solution provider and a formal response from VISA – sort of NESA-lite! Have I missed something?
What you are missing is that the bulk of E2EE solutions are tied to transaction processors and banks that have already unofficially approved of them by offering them in the first place. As a result, to get scope reduction, you typically only have to ask them to get it. But every now and then, you have to ensure that the solution was properly implemented and that sometimes includes a packet capture of encrypted network traffic.
If CHD is on AWS cloud and they are accessing through jump server and have 2FA does that mean the Physical Security is not applicable for their office location. If they use any laptop from their home to access CHD any specific control needed.?
Physical security is still important because you do not want to have people losing gear that could potentially have credentials stored on them even though you have MFA. In addition, anyone accessing your AWS environment should not be using just any computer to access it. It should be a computer that you can be assured is secure and safe. Hence why most organizations do not allow any computer other than a computer they own access AWS.
Unfortunately, not all vendors “got this”. 😉
Both the NESA and P2PE programs are abominations that are nothing but merchant-centric solutions. If the merchant is using encryption-at-the-swipe technologies, the banks should give their merchants a “hall pass” on PCI DSS except for the obvious physical concerns such as overlays.
The Council constantly feels a need to justify it’s existence by making such programs “rocket science” and running the solution providers through the wringer. They tried to standardize tokenization twice and failed, instead publishing more guidance that suggests encryption, hashing, and truncation as methods of tokenization. Really?
While the PCI DSS was a necessary instrument in securing the payments landscape back in the day, my sense is it has ‘run its course” and has been superseded by technology.
The Council should step aside and stop inhibiting security innovators. We got this!