First the National Retail Federation (NRF), then bloggers. Organizations and people are piling on the PCI SSC and standards all because of the United States Federal Trade Commission’s (FTC) fact finding project. Seems like PCI is now a bad three letter word. But with the changes that have been implemented or will soon be implemented, I am starting to wonder about the relevance of the PCI DSS. So I thought I would explore these topics and explain what has lead me to that conclusion.
Ever since the FTC announced there little fact finding mission, I have consistently said that the FTC is late to the party.
Why do I think the FTC is late?
The FTC’s fact finding efforts are I am sure in response to the Target, Michael’s, Home Depot, etc. data breaches which resulted in tens of millions of payment card accounts being exposed and potentially used for fraudulent purposes. Remember, they are a governmental body, so taking action can take a bit of time, in this case at least three years and longer than most people would have desired. But they eventually got around to it. While this fact finding effort is a valid way to get up to speed on a problem, the trouble is that the threat landscape has changed since those notorious breaches and the FTC got its act together.
What in the threat landscape has changed?
The vast majority of mid-sized and large retailers have or are in the process of implementing point-to-point encryption (P2PE) or end-to-end encryption (E2EE) and tokenization solutions to minimize their PCI scope to only the point of interaction (POI) otherwise known as the card terminal. As a result, the threat of large scale breaches at these merchants is or soon will be in the next 12 to 18 months (based on my knowledge of a large number of such efforts) near zero. The reason being is that these merchants’ point of sale (POS) and other systems will no longer have access to cardholder data (CHD) or sensitive authentication data (SAD).
How can the threat be near zero?
The threat with P2PE/E2EE and tokenization limits scope to only the POI and is very, very low because of how the POI must be implemented to work with P2PE/E2EE and/or tokenization. I am not going to discuss in detail the security features of these solutions so as not to tip the hand of those organizations implementing them. Let me just say that there is a lot of information required that must be loaded into the POI in order to swap out terminals. Even then, there are additional controls involving the registration of the device by the merchant and/or service provider that preclude terminal swaps without generating some form of alerts.
The one threat that still does remain is the use of an overlay for skimming cards. But that risk varies from POI vendor to POI vendor and even by POI model within a vendor. And it is not like vendors have not taken notice of the overlay problem. Vendors have gotten a clue and are changing the design of their POI to make them as difficult as possible to use an overlay. I have a client that went with a POI that has various angles, long swipe tracks, LED lights and other features that would make an overlay very expensive to engineer but also very difficult to appear seamless to customers and clerks. Over time I expect to see all POI manufacturers adopt strategies to minimize the ability to use overlays.
The result of all of this is that merchants are no longer the risk (if they even present a risk) they were two or more years ago.
So who or what does that leave at risk?
ECommerce Web sites are still a huge problem. EMV as it exists today does nothing to stem the problem of online fraud. Even if a merchant has outsourced eCommerce, they still have to manage that environment as well as deal with the chargebacks and disputes that come from eCommerce card transactions. I have heard rumors of solutions that are coming to address eCommerce, but I have yet to see any formal announcements of those solutions. So for the foreseeable future, eCommerce will still be in-scope for some amount of PCI assessment. So merchants with an eCommerce presence will likely still have to address some form of PCI assessment for that environment.
Any merchant that has not gotten on the P2PE/E2EE and tokenization bandwagon. All merchants should be getting POI that encrypt and/or tokenize at the swipe or dip of a customer’s card. Adopting such solutions will leave the merchant with only having to comply with requirements in 9.9 and 12. I know for some merchants that will mean an investment, but the payoff is extremely reduced PCI scope and effectively taking almost all of the risk out of card payments.
The organizations that end up with a huge target on their backs are any service providers, transaction processors, issuers or financial institutions that have CHD and/or SAD stored in their files and/or databases. An unfortunate fact of life is that transaction processors, issuers and financial institutions are always going to have to have some amount of CHD/SAD in their files and databases because of the nature of their business. It is these organizations where the full on (i.e., Report On Compliance or ROC) PCI DSS assessment will never go away.
For merchants that have moved to P2PE/E2EE/tokens, I could see a move to an annual self-verification that those solutions are still implemented and functioning as designed. I could additionally see that, every three years or so, the card brands requiring an independent assessment by a QSA/ISA that the controls for P2PE/E2EE/token solutions are still in place and functioning correctly. The reason for independent verification is that changes get made and those changes might affect the environment making it less secure. For merchants not using P2PE/E2EE/tokens, I would think the current SAQs and ROC will remain in place with an annual assessment required.
Will other PCI standards be marginalized or disappear?
The PA-DSS will never leave us. Software developers need to develop secure code and those service providers, transaction processors, issuers and financial institutions that store CHD/SAD need applications that do that securely, so there is a built in constituency for the PA-DSS. ECommerce solutions are also still going to need PA-DSS validation. But regardless of whether P2PE/E2EE and tokenization are implemented, any application potentially dealing with CHD/SAD will need to be assessed under PA-DSS to ensure that any CHD stored is stored securely and is erased securely. Then there are the unknowns of the future. You never know what might come along in the future, so there is always a possibility that some solution might need to securely store CHD or other payment related information. The bottom line is that I find it very hard to believe that the PA-DSS could ever be dropped.
The PTS standard will also not disappear because those POI need to be validated to handle CHD/SAD securely and work properly regardless of P2PE/E2EE solutions. The PTS is the only standard that is a card brand requirement, not a PCI DSS requirement. It is the card brands that demand merchants use only PTS validated POI and I do not see that requirement going away when the POI is going to become the remaining target at merchants.
The ASV standard will not go anywhere as there will still be eCommerce solutions that will require vulnerability scanning. Most merchants will implement eCommerce solutions that minimize their PCI scope using a redirect or iFrame. Although I can see it coming that even using those solutions will still require the merchant’s eCommerce site, now deemed as out of scope, to be scanned for vulnerabilities. The reason is that the invocation point of the redirect or iFrame is at risk of modification by an attacker.
One standard I do believe that will eventually go away is P2PE. The reason is that there is very little to gain with a P2PE versus an E2EE solution. Both solutions are essentially the same, the only additional work required for E2EE is documenting that E2EE has been implemented appropriately and submitting that documentation to the client’s acquiring bank and getting the bank to agree to the PCI scope reduction. As a result, I believe that the P2PE standard will slowly and quietly disappear into the night as the cost of going through the assessment process along with the Council filling fees just cannot be justified by a lot of influential vendors such as Verifone and First Data.
There is my rationale for where I think things are hopefully headed. Only time will tell if the rest of the world sees things the same way.
PCI Guru 
When I was confronted by a Bank if we’d implement P2PE or E2EE we opted for the latter because we could not see any advantages. But the scope reduction comes in handy for third parties that have way less to do with questionnaires/re-assessments and so on.
Few things then I will get on my soap box.
In this post there is mention of tokenization. Today, this is an overloaded term for sure. In our space, it originally was a value that could replace the PAN for settlement and other processes for storage purposes (post authorization). Now we have mobile device payment schemes and a EMV implementation scheme where the PAN data is considered a token. It sill looks like a PAN and can be used and must be protected.
As for the destination of E2EE and P2PE. End to End Encryption only works when the card data is encrypted on an SRED device at the POI and decrypted at the issuer. This is not realistic with the antiquated back end process we still are working with. With today’s technology and online communications we could process transactions directly from merchant to issuer, no middle men required. Of course that would never happen since too many organizations make money on transaction fees and interchange. Of course it would require a huge investment on the issuer’s side. But since they have merchants securing the week product and processing, why change.
With today’s infrastructure, P2PE is the only solution. This is encryption from one point to the other. PCI has assumed the initial point is the POI, but a switch could decrypt from the POI and re-encrypt to the next hope. In this example this would be two distinct P2PE links. We have been doing this for debit for many decades. And it keeps the outdated back end in business.
[Getting on my soap box]
I have been in this industry a very long time and I still have not figured out how the brands, with a very weak product, has made this the merchant’s problem. I know how the business side workes, but how they have convinced shoppers that the merchant is the problem when there is a breach and charges are made on their accounts is what i don’t understand. EMV is a very old standard, however, the EMV card is a computer. It frustrates me that we can not take advantage of the crypto and security of the POI computer (EMV card) to protect this data.
I have a lot more to say about this, but my time is up. So I am stepping down.
Sorry my friend, but non-P2PE validated solutions (E2EE in my vernacular) are just as secure as their P2PE brethren. The reason I say that is that Verifone, First Data, Bank of America Merchant Services and a whole host of other providers would all argue that the only difference between their solution and a P2PE solution is the independent validation and payment to the Council to be on their list. As someone who at one time did do P2PE validation, I would have to agree with their assessment of the P2PE standard.
All that really matters is the merchant is using PTS validated POI devices with SRED as a function and the decrypting point [or end] is decrypting transactions and managing keys in a PCI DSS compliant manner and those processes occur in a PCI DSS compliant data center hence, I could trip at least 80% of nonsense from the P2PE standard.
I guess now the definition of each end is what we disagree on. Unless ” Verifone, First Data, Bank of America Merchant Services and a whole host of other providers” are the authorizing the transaction, they are not the end i was referring to. There are a point in the transactions journey to the authorizer and they would be in scope of P2PE and the PCI DSS. From that POINT they could apply P2PE to the next hope.
We seem to disagree in terminology, not concept of relevance.
If it matters, am deeply involved with the ANS X9 standards organization and went through this painful debate years ago. Like in another comment, some terms and acronyms get way over loader.
In the PCI world, E2EE refers to a solution that could be P2PE validated but has not been. There are a lot of providers of E2EE solutions that do not see the need, relevance or value of validating their solutions to the P2PE standard. Even in P2PE, the transaction endpoints are the merchant POI and the transaction processor/gateway. Although under P2PEv2, the merchant now can also be the manager of the POI endpoint.
You are correct, that it is the endpoints where the risk still exists because they are where cleartext data exists.
I personally don’t see the P2PE standard as we know it today remaining relevant. I seems this entire discussion has been on P2PE and encryption at the swipe/dip solutions, which nearly eliminates merchants’ PCI DSS scope, regardless if the solution is listed on one of PCI Co’s marketing lists.
The P2PE standard has been out, what, since 2012? So in four years there are 17 listed P2PE solutions. It’s not like P2PE solution providers are clamoring to get on the list. Plus, of those 17, one is expired and red and four others are red. I’ve not been able to determine what “red” indicates, but I can only imagine it is bad.
My sense is merchants are opting for encryption at the swipe/dip POI devices that are not part of a listed P2PE solution because: 1) validated/listed P2PE solutions are much more expensive than non-listed solutions, 2) they are typically locked in to a single third party service provider and/or processor FOREVER, and 3) their scope reduction is exactly the same.
Now, I keep seeing the terms “high value PAN” and “high value token.” I suppose the readership can draw its own definitions, but a PAN is a PAN is a PAN. A high value token typically indicates:
1) it is format preserving with digits 7 – 12 hashed [salted or not] or encrypted [which is defined in PCI DSS Requirement 3.4 as “truncation,” so it’s not a token] and could potentially be monetized or used to generate a transaction, or
2) it is a mathematical derivation of the PAN meaning it could be reversed or “detokenized.”
In either example merchants should avoid these types of tokenization solutions in order to keep their Requirement 3 scope at near zero because the QSAs will keep digging and spend more time on site than you want them to.
P2PE solution or non-validated P2PE solution (aka E2EE) both lock a merchant into a transaction processor/gateway. P2PE definitely locks a merchant in much tighter than an E2EE solution because it is much more likely that the E2EE solution is used by other providers. Regardless, in order to change providers, the new provider will have to inject the terminals with their key(s) which will take a lot of coordination and time to complete.
P2PE listings that are marked in ‘RED’ are those solutions that are about to or have passed their reassessment date. If the solution is not reassessed by that reassessment date, then it will drop off the list.
RE: “Of course that would never happen since too many organizations make money on transaction fees and interchange.”
I disagree with overly simplified “making money” justification of this statement. Instead, it is an impossibility based on current payment terminal technology. This would require one of two things: 1) every terminal would need to be seeded with a unique encryption seed from every issuer on the planet, or 2) a master key would need to be used by all terminals and issuers. With the first option, that’s a lot of seeds and the second option would probably give most security professionals the heebie-jeebies – one seed compromised by any means and the world would be open. There is a third option you alluded to where every terminal contacts each issuer directly, I assume using TLS 1.2+ but if you are privy to any of the terminal discussions going on you know that terminals aren’t there yet and I doubt that a majority of issuers have the infrastructure to answer the incoming “direct” authorization. And talk about making money, a lot of people would be making LOTS of money rolling this out world-wide.
The seeds you are referring to is for symmetric algorithms. The use of asymmetric algorithms solves this. We do this today with remote loading of symmetric keys using asymmetric methods. It would take coordination and a trusted certificate authority.
But terminal support for asymmetric encryption is extremely limited or non-existent based on the number of terminals in the wild and this would work for online environments only. Again though, I have serious concerns that a significant percentage of the issuers could setup a reliable and secure infrastructure for direct terminal connectivity to millions of potential merchant terminals. This would require middle-men that have the knowledge and wherewithal and ability to consolidate – remarkably similar to our existing ecosystem and would cancel the true end-to-end (directly to the issuer) that is being championed. I’m all for it if you can get through the technical hurdles but trust me, this is a topic my company and I have tried to address for many years and yes, a trusted “payment authority” is a key component and in all likeliness the biggest target if something were to be devised (I think even more so than the current certificate authorities that we all know and love because these new payment authorities would be focused on payments). This would require automated revocation infrastructure because most terminals are out of the normal merchant IT maintenance and support structure, etc. etc. etc. Ok, I’m ranting, sorry.
What is kind of funny here is that over the years I have posted several “PCI is all about the money” articles and replies to posts — possibly even within this blog site. Then here I sound like a “PCI is great, no money wasted here” fanatic. Trust me, I’m not. It’s just this is an area I am familiar with.
I’m kind of confused by your E2EE or end-to-end-encryption reference. It was my understanding that E2EE only exists on paper in the payment space because it would mean encryption happens at the POI and decryption only occurs at the issuer — end-to-end. I’m not aware of any true E2EE solutions as this would require every POI device to have unique encryption keys for every issuer on the planet. Even First Data, who does act as an acquirer and issuer in some cases could only decrypt for its own issued cards and non-FDC issued cards would have to go to the issue for decryption. If any entity in the middle is able to decrypt, then the solution is considered P2PE.
As far as the merchant is concerned, P2PE vs. E2EE should not make any difference as POI encryption key injection “should” be out of the merchant environment and decryption keys “should” not be available to the merchant to decrypt.
Am I wrong or using an old definition of P2PE or E2EE — meaning did PCI SSC change another definition that I’m not aware of?
Nothing has changed, but it all depends on the location of your end points. 🙂
For the purposes of PCI, E2EE is just P2PE without the independent validation and listing on the Council’s Web site. Using an E2EE solution was always allowed, there was just some additional work needed by the QSA/ISA as well as approval from the acquiring bank on scope reduction. And remember, with P2PEv2, now the merchant can do the key management.
In the payments space we have a common definition of P2PE because there is a security standard in the field that defines it. That said, I could trim 80% of nonsense from it. There actually could be several different definitions of the acronym E2EE, so it shouldn’t be used interchangeably with P2PE. With E2EE the initial point of encryption could be a POS server in the back office, meaning there would be unencrypted cardholder data [albeit pre-auth] floating around the merchants CDE along with additional PCI DSS scope thereof. That is likely the case with hundreds of thousands of Level 4 merchants today with SSLv(?) baked in. If it’s not a validated P2PE solution, the analogous term is “encryption-at-the-dip/swipe.”
Then we can all agree that if the merchant is using PTS validated POI devices with SRED as a function, their experience is exactly the same as with a validated P2PE solution. That’s what the merchants want as cheaply and expeditiously as possible. They want nothing to do with PCI DSS and cardholder data. They want to focus on being a merchant and not being a Requirement 1 – 12 security expert.
And it really doesn’t matter where the other “point” or “end” is or how encrypted payloads are decrypted or how P2PE keys are managed as long as those processes occur in a PCI DSS compliant manner inside a PCI DSS compliant entity. If the PCI Council, acquirers, and the QSA community take this approach, SRED POI devices would be flying off the shelf and there would be a lot less cardholder data at merchants to steal. Instead merchants are slow to adopt encryption-at-the-dip/swipe technologies because of compliance officers’ checkbox approach to a marketing list. Very sad.
I understand your points Steve. When I use E2EE in the context here, I mean a solution not validated to the P2PE standard.
We are planning to replace our business system to well known and most popular in its type. However they say they do not support tokenization in UK, although they do in USA. Some legal or regulatory work needs to be completed apparently. If we migrate to that new software by the end of the day and if they still do not support tokenization, I think that expensive investment would be not logical. Last year our service provider offered us migration to the cloud helping to reduce PCI scope, with that it has offered new card terminals which did not support P2PE/E2EE afaik. It seems vendors do not help much to reduce the scope.
It does not sound like you get much of a choice.
That said, does that first solution support P2PE/E2EE? Does this solution get the PAN back from the processor? I am assuming that the PAN comes back based on your message. If so, did the processor explain why they are sending the PAN back? This solution sounds like a much better option than the cloud solution.
While I agree with most everything in your post I am a little confused, your definition and scope reducing capability of E2EE seem to have changed. From PCI Guru, August 24, 2014:
“P2PE is a subset of E2EE. This is because the major difference between P2PE and E2EE is that P2PE does not allow the merchant to be a manager of the encryption keys. Under the P2PE standard, only the transaction processor or other third party is allowed to perform key management. The merchant is never allowed to perform encryption key management under the P2PE standard. As a result, DUKPT can be used by both P2PE and E2EE solutions. However, under P2PE, the key management must be done by a third party, not the merchant.”
Did I miss an update to the definitions? I have been steadfast in P2PE being the only accepted solution for us as E2EE doesn’t reduce our scope.
One of the big changes with P2PE v2 is that it does allow for the merchant to manage keys.
As I said in my post, there is very little advantage of P2PE over E2EE other than having to go to your acquiring bank and asking for their approval for scope reduction.
Who are you and what did you do with Jeff Hall? Are you trying to start a revolution or something? Welcome to my cause!
“I am starting to wonder about the relevance of the PCI DSS.”
PCI DSS relevance to the merchants? Yes, after all card present operations on the planet are running encryption at the dip/swipe and tokenization.
[Tokenization Editorial – Some tokenization solution providers use encryption, hashing, and truncation, which are poor designs and already covered in PCI DSS Requirement 3. Merchants should seek tokenization solutions that do not mathematically derive tokens from the PAN, do not use encryption, hashing, or truncation, and do not return a format preserving token. To truly qualify as a token it should comprise a randomly assigned alpha-numeric character string. Anything less than that and the merchant should have some Requirement 3 scope, where the QSA needs to understand key management, among other areas, and who has access to cryptographic keys. The PCI SSC should not have given credence to poorly designed tokenization solutions in its half-baked guidance.]
As you point out there still needs to be a security standard for ecommerce merchants – OWASP! Why re-invent the wheel? Gateways and processors should self-assess against ISO 27002. The other entities…issuers, banks, ISOs, and such should continue to roll up to the card brand rules and FFIEC/IT or other regulatory entity. I know some folks at ISOs that would be tickled pink to only have only one security standard to be audited against.
It’s also about the PCI SSC’s relevance and what they should be meddling in, if anything. It’s a well-known fact the PCI SSC has stymied merchants’ adoption of P2PE solutions because of a marketing list the maintain. Let’s put this into perspective. P2PE solutions benefit only one entity…merchants. Why? Because the decrypting points can’t use the SAQ-P2PE. As long as merchants are running encryption at the dip/swipe, it really shouldn’t matter how the decrypting points process P2PE transactions, as long as they remain compliant with PCI DSS [or whatever security standard the FTC prescribes]. I could slash at least 80% of nonsense from the P2PE standard, especially Domains 5 and 6 where they re-invented the wheel. Something else I never understood is the P2PE QSA must visit/validate every key injection facility that is part of the P2PE solution. Visa certified ESOs? Hello? Whatever happened to the auditing concept of auditors accepting written opinions of others? I’m personally aware of some KIFs that complain about being audited for the same thing by different P2PE QSAs over and over again.
“The PA-DSS will never leave us.”
Never say never. I agree, if you are referring to applications inside POI devices. But traditional payment applications that natively process, store, or transmit cardholder data today would be nothing more than a business application when P2PE and a well-designed-tokenization solution is implemented. With encryption at the dip/swipe a merchant could run its card present operations on Windows 3.2 with no firewalls or antivirus if they so desired. Insane, but true.
The problem with the standards you cite is that they are generic and do not deal with the special issues of protecting specific data. In the case of PCI, we are protecting sensitive authentication data (SAD) and cardholder data (CHD). Just as the HIPAA HITECH standards focus on the protection of personal health information (PHI) as dictated by HIPAA. In addition, the PCI standards go into much more detail than OWASP, NIST, ISO, etc. in certain areas because of a desire to ensure better compliance and security. Besides, OWASP and other standards are incorporated into the PCI DSS and other PCI standards, so it’s not like they have been left out or ignored.
As long as the PAN has high value, PCI DSS, PTS, PTPE, PADSS…. will be relevant.
I would like to defend the PCI SSC a little based on this comment: ” It’s a well-known fact the PCI SSC has stymied merchants’ adoption of P2PE solutions because of a marketing list the maintain”
The PCI SSC is only supposed to write “standards” the enforcement is supposed to be at the brands. I would say that the underlying issue is that when you try to innovate there is not one place to go get a “that will work” answer. PCI SSC will refer the the brands. The brands don’t necessarily have the expertise on security solutions or can agree that it will meet there own processing rules. It is very difficult to design a product when you don’t know it can be approved across the board. And have a product that works for one brand only does not provide a good ROI.
But if the PAN is encrypted or tokenized immediately when a card is swiped/dipped, then are you really going to go through the entire PCI DSS to validate that solution? I seriously doubt it because the only thing that is in-scope at the merchant is the point of interaction (POI) and nothing else. That was my point. And even then, the merchant 99% of the time, does not even manage the POI. That is done by the transaction processor. So other than ensuring the security of the POI and making sure that there are no overlays on the POI, what else can the merchant do?
Your quotation of, “The brands don’t necessarily have the expertise on security solutions” really took me aback. Obviously, you do not understand who drives the bus on the PCI standards. While the Council manages and publishes them, it is the brands (predominately Visa and MasterCard) and the participating organizations (PO) that drive the content of the PCI standards. And having interacted with a number of the brands’ security experts, I can tell you they know as much, if not more, than a lot of information security professionals. So do not kid yourself into believing the brands have no clue.
Well, for some reason I was not able to reply to your comment. Any way, my point is this, as long as the PAN is a high value data element, it starts in the clear and is processed in the clear. The attacks simply move to the end points. I actually would love to have a conversation with you sometime over beverages. We don’t know each other, but we have expertise in opposite areas of the industry. My bottom line point is that high value data that is ever stored, processed or transmitted is ever in cleartext form cannot be protected from data breaches.
Sorry, but replies are approved by me before they are made public and I see your reply you mention here as the next one.
Regardless of PCI, any sensitive information processed, transmitted or stored in cleartext is highly at risk. But with P2PE and E2EE (non-validated P2PE) solutions, the endpoints are the merchant POI and the system(s) at the transaction processor or transaction gateway. So the one piece still at risk with the merchant is the POI because the POI comes into contact with sensitive authentication data (SAD) in cleartext. This is why the transaction processors/gateways, issuers and acquiring banks will become the targets of attackers because they will be the remaining sources of SAD and cardholder data (CHD).