End to End Encryption & Tokenization…is this really a debate?
May 26th, 2009 by cmark Posted in PCI DSSAdded Amusing story about end to end. Read: The Inoculation Effect; from Marines to End to End Encryption
I just finished reading an article in the Greensheet related to end to end encryption. While the article does a very good job at showing the different angles and arguments for and against the concept, it is disturbing that the concept is being summarily dismissed by some people in the industry. I have been fortunate to have worked with a number of companies that have developed end to end (actually point to point) and tokenization type solutions. These solutions represent a very big step forward in data security within our industry.
On the third page of the article it states that “…it is generally thought that even unencrypted data is safe when the PCI DSS is strictly followed.” Having been a QSA, card brand employee, and QSA trainer that has worked with over 100 very large banks, processors, and merchants, I can tell you definitively that not a single one with which I worked was able to ’strictly’ follow the PCI DSS in such a way as to make unencrypted data “safe”.
There is an argument in the article against tokenization that says: ”the risk is focused upon a particular entity, as opposed to spread out among various entities.” Really? This is an argument against tokenization? Keep in mind that Tokenization solutions are offered primarily by gateways and that gateways have their merchant’s data anyhow. These tokenization solutions remove data from the merchants that don’t really need it. Instead of 1,000 potential points of compromise, you now have a single point of vulnerability (the gateway). Regardless of whether they were offering a tokenization type solution or not, the gateway would be a target for data thieves. The person who made the previous statement then goes on to say: “And you are reliant upon a single entity, that entity has to be hardened and secured beyond any potential doubt.” Any potential doubt? This is difficult to understand. Is he saying that this entity must be PCI DSS compliant? If we are conceding that the PCI DSS represents the “best line of defense against a data compromise” as also stated in the article is it not enough to ask the companies providing the tokenization solutions to be PCI DSS compliant? As we all know, there is no guaranteed security.
Consider the following scenario. Gateway X provides payment processing services for 5,000 level 4 retail merchants. These level 4 retail merchants are using an IPOS provided by some VAR. They don’t have a firewall, IDS, or a security policy. While they are required to comply with the PCI DSS, they are not required to validate. Furthermore, even if they were required to validate, they simply do not possess the technical aptitude to install and maintain a web application firewall, intrusion detection system, file integrity monitoring or many of the other 230+ sub requirements. When they accept a card for payment, the data is stored locally on their IPOS and sent to their gateway for follow-on processing. In this situation, do you have 5,001 points of potential compromise? No, you likely have 7,001 or more as many of these merchants have more than a single POS or location. Since Gateway X already has the merchant data, they offer to allow their merchants to NOT store the data and instead provides a token for the merchant to store. Now we have reduced the points of vulnerability from 7,001 to a single point of vulnerability (the gateway). Gateways generally have the technical ability and the vested interest in protecting the data. Is there a risk that they will be compromised? Certainly. Have we reduced the risk to that data? It is hard to understand how we have not.
Let me be clear. We are a long ways off from end to end encryption being employed in most large merchants. Most level 4 retail merchants however can benefit from tokenization type solutions and end to end encryption solutions. In fact, while this is not public knowledge, I personally know of three Level 1 retail merchants that have removed nearly all of their data through tokenization solutions.
Is there a potential vulnerability in these solutions? Sure there is. Are these solutions appropriate for all merchants? Certainly not. Can many, many of the 6 million plus level 4 merchants (that are not currently compliant with the PCI DSS) benefit from these types of solutions? Absolutely!
Bob Russo states in the article that: “We (the PCI SSC) will continue to advocate for the PCI standards as an organization’s best line of defense against data compromise.” My question is; “Why do the concepts of PCI compliance and end to end encryption or tokenization have to be mutually exclusive?” Consider PCI compliance as a spectrum. On one end you have 233 requirements with which you must comply. On the other end you have a handful of requirements. The number of requirements is predicated upon whether you store, transmit, or process data, and in what manner. If I use tokenization for nothing more than replacing stored data, I have just removed a huge technological and administrative burden from my company. Simply not having to “Protect Stored Data” as per 3.4 of the PCI DSS, saves me a huge amount of money and complexity. By using tokenization, I have addressed 3.4 of the PCI DSS.
I find it unbelievable that we would be having a debate as to the value of end to end encryption and tokenization. When I was training QSA’s I used to really enjoy the hard core techies that could come in and make a compelling argument that any form of encryption was worthless. Many of these were folks that had come from the various government agencies and would make very compelling arguments. Truth be told, however, we are not in the “absolute security” business, we are in the “risk management” business and tokenization type solutions and end to end encryption solutions represent better risk management for one reason….they REMOVE THE DATA. No Data, No Risk to the data.
In reading the article, it was obvious that some of the people had a vested interest in seeing such solutions discounted. This is expected. My suggestion is that as a merchant you take a long hard look at these ‘alternative solutions’. Because we love you, we are providing (free of charge) some companies that offer good solutions. If you know of any more, please post them here in the comments!
- Heartland Payment Systems (end to end)
- TrustCommerce (end to end w/vault)
- ProPay (end to end w/vault)
- Shift4 (Tokenization w/vault)
- MerchantLink (Tokenization w/vault)
- EPX (Tokenization w/vault)
- PPI (end to end w/vault)
- BrainTree (end to end w/vault)
- Network Merchants (tokenization I think)
- MagTek (encrypted MagStripe Reader supports End to End)
- Semtek (encrypted MSR supports End to End)
- HomeATM (encrypted Pin Entry Device; PED2.0 Approved)
- VeriFone (end to end; for IPOS)
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
3 Responses to “End to End Encryption & Tokenization…is this really a debate?”
By Security Ninja on May 29, 2009
Excellent post, I completely agree with you and I don’t do that often
End to End encryption and Tokenisation is the next natural progression for the PCI DSS in my opinion.
By GTK on May 29, 2009
Many of the retail merchants I am working with in Canada have accepted the fact that they don’t need to store cardholder data post-authorization. The problem is that because they are using POS systems that are integrated with the PIN Pad, and a middleware application installed on the POS till is handling authorization, etc - the POS itself, the underlying OS, and all connected systems fall into PCI scope. Although I have not worked with the technology, I assume this would be the case even if a tokenization solution like Shift4 were used - because these functions occur on the POS computer itself, it pulls the POS into scope. In any case, Canadian merchants generally will not go with a US based acquirer or payment gateway.
I have yet to see an end-to-end solution (at least in Canada) that provides for an POS application integrated with the PIN Pad, where the PIN Pad itself handles encryption of the PAN, and the PAN never appears outside the PIN Pad in an unencrypted format. If this were the case, I think you could make the argument that the PCI scope is merely the PIN Pad, because as a PCI PED compliant device, it provides adequate segmentation from the rest of the network.
Some of my merchants are seriously considering moving back to standalone PIN Pads because of this very issue — but this means that cashiers must manually type the transaction amount into the PIN Pad.
I’ve been trying to get some information from VeriFone on their solution, but if anyone has any other suggestions, I’d be happy to hear them! I have heard “rumors” that Moneris and Desjardins may be developing something along these lines.
By YT on May 29, 2009
Great analysis. While merchants should really evaluate which solution lowers their risk the most in their environment, our philosophy is to remove the data from the entire system – the storage, the capture and the back-office exposure. Like you pointed out - no data, no risk. And why would merchants spend time managing payment data security when they aren’t in the business of managing payment data security? Wouldn’t they rather spend time growing their own business? In response to your last statement, here’s another name for your list of payment security solution providers. CyberSource offers remote tokenization with hosted storage, hosted payment fields, and centralization of payment data infrastructure across channels. http://www.cybersource.com/paymentsecurity.