After Seven Months, Why Does The PCI Council Yet To Have <i>Anyone</i> P2PE Validated?

Tools

This GuestView column is from J. David Oder, the CEO of Shift4 Corp., an independent payment gateway company.

For the past two years, the Payment Card Industry Security Standards Council (PCI SSC) has been taunting merchants with offers of a specialized (and simplified) Self-Assessment Questionnaire (SAQ) for those using "validated P2PE" approaches. At first, the council told merchants to wait while it drew up plans to validate the products. Then—finally—seven months ago, PCI SSC released its standards and told merchants to go right ahead and pick one of these validated options. There's only one problem: As of Thursday (Feb. 7), the council hadn't validated any.

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

Why? Well, quite frankly, because the council designed the wrong standard. Pandering only to massive merchant organizations (that 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 approaches. A hardware/hardware approach requires P2PE hardware at the merchant location and a hardware-based key management and decryption tool—known as a hardware security module (HSM)—at the other end. Only merchants with in-house "switch" systems have this set up and, for those that don't, the infrastructure costs are astronomically prohibitive. This move denies the P2PE benefits, which have been lauded by the PCI SSC for the past two years, to more than 90 percent of its members.

Then, in December, realizing the limitations of its prior attempt, the council released a new standard: a hardware/software "hybrid" standard for P2PE that still requires hardware encryption but that also allows software decryption—so long as the keys are still managed by an HSM. HSMs are not perfect and have been breached.

The fact that PCI has made the HSM an untouchable "black box" means vendors don't get to validate the code it runs. Vendors have to use someone else's certified HSM. Essentially, the council is asking vendors to trust some HSM manufacturer with not only their customers' data but with their whole livelihood. If that HSM goes down, vendors may not be able to fix it.

We in the vendor community would have to entirely rely on a third party to keep our product running. Not to mention that it would likely put us in violation of PCI DSS requirements 2.2.1 through 2.2.3, which state that each component in our environment must be validated.

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, but 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? Haven't enough companies been burned that way already?

The new hybrid approach 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, the coucil has once again left those of us who know better than to place blind faith in an HSM out in the cold.Third-party payment organizations that provide the benefits of a hopefully secure, reliable payment package to merchants without enormous IT and information security (InfoSec) staffs have essentially been forced to play the P2PE game with one hand tied behind their backs. That's true at least until the PCI SSC decides to release an applicable set of guidelines.

Why has the council done this? Does it believe software is inherently less secure than hardware? I'm sure that's a question 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 could be picked up from HP or Dell for a few hundred bucks.

What, then, makes them any different from the secure servers some vendors have running their decryption software? A name? If we, for example, put our package on one of these magical boxes, could we become the first listed 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 provider that just blindly "follows the standard."

Now let's add one more layer to the irrationality. A PCI-compliant, Level 1 service provider running PA-DSS-validated applications is permitted by the PCI SSC to transmit cardholder data in the clear within a compliant datacenter. Now, we never do something so foolish, but by the PCI SSC's own standard, our security methodology has been judged stringent enough to allow us to do it if we desired.

Therefore, such a vendor could receive and/or hold merchants' cardholder data in the clear, but they can't decrypt it. Does that make any sense?

Either that vendor's environment is secure and functional, or it isn't. We would think that the 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 not secure, then the PCI SSC is—by extension—saying its Level 1 Service Provider standard is no longer sufficiently secure, at least for P2PE transactions. If that is true, then no merchant wanting 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 P2PE's scope-reduction capabilities were about to make the PCI SSC all but irrelevant. When properly implemented, P2PE wipes out 10 of the council's 12 security requirements. And so, while it still had power and clout enough to pull it off, the PCI SSC made a land grab, safely encompassing P2PE within its power before it was robbed of much of that power.

To give the council time to react and think things through, it issued a standard that keeps those organizations with the technology and presence to spread P2PE and its benefits safely out of play. Perhaps that is giving PCI SSC too much credit. It may well have been less malicious or simple ignorance. Either way, refusing to validate equally secure approaches, in my opinion, represents a potential restraint of trade for those 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.