12/02/2014

Shift4, P2PE, and PCI Validation

Shift4, P2PE, and PCI Validation

Update 4/19/17: Shift4’s point-to-point encryption solution, True P2PE, is now PCI validated. We were able to build a unique solution that met the PCI SSC validation requirements without compromising our own high standards for speed, security, and reliability. Because of this, some of the information in this article (which was published in 2014) may not reflect our current stance and policies on the topic.

Shift4 was the very first member of the Payment Card Industry Security Standards Council (PCI SSC). Despite our position as its earliest adopter, it’s no secret that we don’t always see eye to eye with PCI on their policies.

PCI’s Stance on P2PE
For most of the past four years, Shift4 has been engaged in a dialogue with the Council about the different methods of point-to-point encryption (P2PE). So far, PCI has only validated hardware-based P2PE solutions that require 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. As we said 18 months ago, “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 the PCI SSC for the past two years – to more than 90% of its members.”

PCI Promises to Deliver a Specification for Software-Based P2PE
At PCI’s 2013 North American Community Meeting in Las Vegas (where Shift4 paid a six-figure sum to act as the Diamond Sponsor in the hopes of finally gaining PCI’s ear), the Council promised that a P2PE specification allowing for software-based decryption was coming early in 2014. Software-based P2PE is the method preferred not only by Shift4, but also by several of our largest competitors, which makes it the solution in use by most merchants today. You can understand the industry’s enthusiasm that this large group of merchants would finally be able to take advantage of the scope reductions and simplified PCI assessments that they’ve been promised for the past four years. Well, Q1 2014 came and went with no standard, as did Q2. In fact, more than a year has now passed since we heard that empty promise.

PCI Claims That “Software Is Not as Secure as Hardware”
At PCI’s 2014 meeting in Orlando, we took to the open mic to ask when PCI was finally going to deliver the software P2PE specification that the industry (and thousands of merchants who already have software-based P2PE in place) have been waiting for. The answer we received shocked us. PCI Director of Data Security Standards Lauren Holloway told us (and the hundreds of PCI Qualified Security Assessors (QSAs) in the room) that they no longer plan to release the software P2PE specification because they believe that software is not as secure as hardware.

The Problem With PCI’s Claim
Now, let’s think about this logically. What is hardware? Hardware is a box full of wires and chips. What does hardware need to perform a task? It needs software that tells it what to do. So, PCI is telling us that hardware is inherently more secure than software… but software is running on the very hardware in question.

Does that make sense to you? No? You’re not alone. In the weeks following PCI’s staggering proclamation, we heard from several of the QSAs and other security experts in attendance who were equally confused. Many of these professionals have reviewed Shift4’s software-based P2PE solution and have found that it not only meets and exceeds all of PCI’s requirements, but that it actually can be used to remove all cardholder data from the merchant environment, making PCI compliance all but irrelevant to the merchants (and making them a non-target for hackers looking for card data).

HSMs at the Heart of PCI’s Claim
So what is the basis of PCI’s claim? At the heart of PCI’s P2PE specification is a hardware security module, or HSM. What’s that? It’s essentially a hardened computer server that is supposed to be tamper-proof. Guess what HSMs need to run? Software. Strip away the fancy name and the physical tamper-proofing, and the HSMs that meet PCI’s requirements are little more than off-the-shelf servers you could pick up from HP or Dell for a few hundred bucks. 

How can an HSM-based solution be more secure than a software-based solution if the HSM runs similar software? The answer must come down to tamper-proofing. If you try to get into an HSM, it will essentially self-destruct, wiping out all the data contained on the server.

We recently opened a data center in the Switch SUPERNAP, one of the most secure hosting facilities on the planet. If you try to gain access to one of our secure servers, you’re going to run into heavily armed security who will wipe out a lot more than just data. But we digress….

Drawbacks to HSMs
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 – and the very ability for merchants to accept payments. 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 mandate our validation of each component in our environment.) That is just not acceptable. 

PCI’s Claim Calls their Level 1 Service Provider Certification Into Question
Now, let’s look at the great paradox of this whole situation. On the one hand, Shift4 is a PCI-compliant, Level 1 Service Provider. 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.) From the very beginning, Shift4 has used software within these data centers to manage keys for our PA-DSS-validated payment applications.

In other words, our software – according to PCI’s most stringent PA-DSS requirements – and our environment are secure enough to process merchants’ non-encrypted cardholder data and to manage the keys necessary to decrypt that data as it is received, but – according to PCI’s P2PE requirements – that same software is not secure enough to decrypt P2PE cardholder type of data for the fraction of a second required to process it.

We’re talking about the same type of cardholder data in both instances, so then how can there be two qualities of protection from the same organization for the same type of data, one that allows us to receive it and store it in the clear within our software-based system and another that does not allow for the same data within the same system to be decrypted at all?

Insinuating that the PCI P2PE standard provides a level of security higher than the Level 1 Service Provider certification we have already completed calls into question the security not just of Shift4, but of card issuers, card processors, card acquirers, gateways, and others in the transaction flow, and even the card brands themselves. By this confused dual standard, all of these organizations must be deemed not fully secure because they all fall under that same Level 1 Service Provider certification that is now somehow less secure than the P2PE certification.

We are certain it was not PCI’s intention to cast a shadow of uncertainty across the whole of the payments industry with this declaration that HSMs somehow trump the existing security standard for its largest stakeholders, but that is exactly what has happened. And in the process, they have denigrated the efficacy and potentially tarnished the reputation of each of the assessors who have spent the last decade validating these solutions and service providers.

The Power of Software-Based P2PE
Thousands of merchants using Shift4’s solutions have been assessed and have been declared PCI compliant. The QSAs we have talked to have all said their opinion of our P2PE offering has not changed and it continues to be one of the strongest solutions available. In fact, leading QSA firm Coalfire Labs performed an external review of our solution running in a major retailer’s environment last year and determined that they had zero card data, so their PCI scope was limited to access controls and physical security.

Add to that the report from one of our partners in the hospitality space who recently built our P2PE and tokenization solutions into their property management system. After spending $30,000 on an assessment to be named a PA-DSS-validated payment application, their PA-QSA firm (perhaps the world’s best known) replied that they were unable to validate the solution as a payment application because no payment data was ever stored, processed, or transmitted within the solution. You don’t get much more secure than that!

These are strong solutions we are confident in saying would have prevented the recent string of major data breaches that have affected hundreds of millions of consumers and cost businesses billions of dollars. Unfortunately, another unintended consequence of PCI’s refusal to validate these solutions is that they are driving merchants – who desperately need this type of security – away from the very solutions that could help them.

The Harm of a “Checkbox Security” Mindset
The “checkbox security” mindset that PCI has created – and that new PCI GM Stephen Orfei admits needs to be tempered in favor of an approach based more on actual, long-term security – has left in its wake an industry full of checkbox-oriented QSAs and bankers who look no further than the stamp of certification when comparing solutions.

These uninformed professionals are loudly (and falsely) declaring that merchants must have a validated P2PE solution to have any hope of being secure. In the process, they’ve turned PCI’s extremely limited list of certified P2PE solutions into a monopoly that is directly impacting the business of hundreds of other solution providers and interface vendors. Again, restraint of trade was likely the last thing on PCI’s mind when they made this decision, but they have to realize as an industry standards body their decisions are wide reaching and have rippling ramifications for not only their thousands of participating organizations, but also for the millions of merchants who rely on those service providers to securely process payment data.

The Best Protection Against Breaches
Combining P2PE, tokenization, and EMV gives the merchants their best possible protection against falling victim to the next breach. The vast majority of retailers who have P2PE in place today are using a software-based decryption method provided by Shift4 or one of our competitors – nearly all of which are Level 1 Service Providers who meet and exceed PCI’s most stringent standards. To deny these thousands of merchants the benefits of a validated P2PE solution merely because their validated service providers came up with a different (and arguably more effective) method than PCI would have liked is truly unfortunate. To do so after the solutions have been declared by PCI’s own QSAs to be secure and compliant is absurd.

Shift4’s Call to PCI and Fellow Service Providers
We call upon PCI to reconsider their decision and to publish their promised software-based P2PE specification. We also request that they issue a clarification in regards to Lauren Holloway’s unfounded and misinformed proclamation that software cannot be as secure as hardware.

We call upon our fellow service providers to continue to develop and offer innovative security tools that keep cardholder data out of the hands of cybercriminals. If our innovations take a different route than PCI would like but lead our merchant customers to a more secure future, then it is our duty to make those leaps and let PCI catch up.

What You Can Do
And finally, we call upon merchants to look past the checkboxes on their PCI assessments and determine which solution is most likely to actually keep their patrons’ data secure. PCI compliance didn’t save Target, Home Depot, or any of the others who have lost millions as a result of not fully securing their card data environments. Solutions exist today that can – and do – secure this data. It is the merchants’ responsibility to find and implement them. If their data is secure, compliance will come as a byproduct.