February 5, 2013

Why Shift4 is Not (Yet) a PCI-Validated Provider For P2PE

That’s right. Seven months after the standards were released and nearly two full years from their initial announcements on the matter, the PCI SSC has yet to validate a single P2PE solution provider that can offer the promised scope reductions and a simplified SAQ to merchants.

Why? Well, quite frankly, because they designed the wrong standard. Pandering only to massive merchant organizations (who not only hold weight in the industry, but also hold seats on the Council), the SSC built a P2PE standard that applied only to hardware/hardware solutions. A hardware/hardware solution requires P2PE hardware at the merchant location and a hardware-based key management and decryption tool – known as an HSM, or Hardware Security Module – at the other end. Only merchants with in-house “switch” solutions have this setup, and for those who don’t, the infrastructure costs are astronomical and prohibitive for all but the largest merchants. This move denied the benefits of P2PE – that have been lauded by PCI SSC for the past two years – to more than 90% of its members.

Then, in December, realizing the limitations of their prior attempt, the council released a new standard: a hardware/software “hybrid” standard for P2PE that still requires hardware encryption, but that allows software decryption – so long as the keys are still managed by an HSM.

HSMs are not perfect – we all learned that a few years ago when a major HSM provider was breached. The technology has improved since then, but so have the frequency and efficacy of attacks. The fact that PCI has made the HSM an untouchable “black-box” means solution providers (like Shift4) don’t get to validate the code it runs. We have to use someone else’s certified HSM. Essentially, they are asking us to trust some HSM manufacturer with not only our customers’ data, but with our whole livelihood. If that HSM goes down, solution providers may not be able to fix it. We would be entirely reliant on a third party to keep our solution running. (Not to mention it would likely put us in violation of PCI DSS requirements 2.2.1-2.2.3 that require us to validate each component in our environment.) That is just not acceptable.

How does this new hybrid standard address those issues? Well, frankly, it doesn’t. It makes things worse! Now not only are there HSM issues to worry about, we also have to accept the fact that – according to PCI – the HSM can pass the keys (in the clear so long as the network is “properly segmented”) to the software decryption stack. Keys in the clear on a segmented network? Didn’t that already lead to one of the biggest breaches of the last decade?

The new hybrid solution does allow a few new players into the marketplace – but at what potential cost? Yet again, the PCI Council has released a standard that will allow less-than-adequate security measures to be checked off as “compliant.” And, they have once again left those of us who know better than to place blind faith in an HSM out in the cold.

So, who’s looking out for the rest of us? Unfortunately, no one. Shift4 and the rest of the third-party payment organizations who provide the benefits of a secure, reliable payment solution to merchants that don’t have enormous information technology (IT) and information security (InfoSec) staffs have essentially been forced to play the P2PE game with one hand tied behind our backs. (At least until the PCI SSC decides to release an applicable set of guidelines.)

Why have they done this? That’s the part we really don’t understand. We have a functional P2PE solution that is powered by our time-tested Universal Transaction Gateway® (UTG®) and that offers even greater security than the hardware/hardware solution they support, yet ours can’t be validated. Why? Do they believe that software is inherently less secure than hardware? I’m sure that’s a question that engineers and programmers could debate for hours – but it’s irrelevant because the HSM runs software. Strip away the fancy name and the physical tamper-proofing, and the HSMs that meet PCI SSC’s requirements are little more than off-the-shelf servers that you could pick up from HP or Dell for a few hundred bucks.

So, what then makes them any different from the secure servers we have running our decryption software? A name? If we put our solution on one of these magical boxes, could we become the first listed solution provider? As ridiculous as it sounds, maybe it’s worth looking into. It would certainly offer users more security than they will see from another solution provider that just blindly “follows the standard.”

Now, let’s add one more layer to the irrationality. Shift4 is a PCI-compliant, Level 1 Service Provider running PA-DSS-validated applications. This means we are permitted by the PCI SSC to transmit cardholder data in the clear within our compliant data center. (Now, we’d never do something so foolish – but by their own standard, our security methodology has been judged stringent enough to allow us to do it if we desired.) So… we can receive and/or hold merchants’ cardholder data in the clear, but we can’t decrypt it. Does that make any sense?

Either our environment is secure and functional, or it isn’t. We would think that our Level 1 Service Provider status would prove that it is both secure and functional. If, by the new P2PE standard, we are now judged to be unsecure, then PCI is by extension saying that their Level 1 Service Provider standard is no longer sufficiently secure – at least for P2PE transactions. If that is true, then no merchant desiring to implement P2PE can currently be secured by a PCI-validated organization.

This seems ill-thought-out by the PCI SSC. Like everything else about this P2PE regulation, it seems reactionary rather than methodical. Now, we can’t be sure, but we have a theory as to why. Our hypothesis is that the council realized that P2PE’s scope-reduction capabilities were about to make them all but irrelevant. When properly implemented, P2PE wipes out 10 of their 12 security requirements. And so, while they still had power and clout enough to pull it off, the PCI SSC made a land grab, safely encompassing P2PE within their power before it robbed them of much of it.

To give them time to react and think through it, they issued a standard that kept those organizations (Shift4 included) with the technology and presence to spread P2PE and its benefits safely out of play. Perhaps that is giving them too much credit; it may well have been less malicious or simple ignorance – but either way, refusing to validate equally secure solutions in our opinion represents a potential restraint of trade for Shift4 and many of our colleagues (and competitors) in the payments space. It is not a move we take lightly and we call upon the PCI SSC to immediately act to remedy such restraint or to prepare to face possible litigation.

Shift4 stands by the security of our product offerings. We also stand by our merchants. For years now, we have had the most secure payment solution available stretching from the end of the serial or USB cable in the merchant environment to our secure data centers. Now, we have a solution that extends from within the secure payment device to our secure data center. With our P2PE solution, the only place we ever decrypt the data is inside of our PCI-compliant data center and even then we re-encrypt it within fractions of a second. No one ever sees our encryption keys. Our solution is as secure as any offering on the market or any technology proposed by the PCI council.

We have invested years of research and significant capital into our P2PE solution and it ought to provide all of the benefits long-promised by the PCI SSC. We are currently rolling that solution out to merchants and are prepared to fight whatever fight we must to guarantee them the scope reduction and simplicity that P2PE provides. As soon as there is a standard for us to achieve – one that applies to our solution and that guarantees the security our merchant customers deserve – we will be first in line for validation.