Visa’s Retail Token Advice Of Token Value
Written by Evan SchumanVisa on Monday (Oct. 5) issued a document to ostensibly help retailers figure out how best to navigate the new encryption and tokenization landscape. But as a practical matter, the document did little beyond rehash conventional wisdom and long-standing Visa and PCI best practices. It felt more like a quintessential psychologist’s advice session: “Dr. Visa, what should we do about tokenization?” “That’s an excellent question, Mr. CIO. What do you think you should do?”
The document danced around the key issues about which retailers would truly love strong guidance from Visa, ranging from whether tokens could ever conceivably be considered out of PCI scope to whether retailers are actually encouraged to retain such tokens on their own servers.
The only explicit advice that Visa’s document gave spoke to issues that have, for all practical purposes, already been decided. For example, the document touched on the encryption technique that many vendors are inaccurately calling end-to-end encryption. Visa has chosen to call that approach—where the card data is encrypted or turned into a token a split second after the card is swiped—Data Field Encryption. (It’s not the catchiest term, but let’s give points to Visa for refusing to use the inaccurate end-to-end name. At least Data Field Encryption is descriptive and accurate.)
It took the position that Data Field Encryption is viable and worthy of evaluation. That would have been helpful a year or two ago, but it’s such a foregone conclusion today as to be of little strategic help.
“While no single technology will completely solve for fraud, Data Field Encryption can be an effective security layer to render cardholder data useless to criminals in the event of a merchant data breach,” said Eduardo Perez, global head of data security at Visa Inc. “Using encryption as one component of a comprehensive data security program can enhance a merchant’s security by eliminating any clear text data either in storage or in flight.” A true statement, but it’s hardly one that will prove especially enlightening for retail chain IT execs. Their questions are mostly “which approach” and “how should it be deployed.” Alas, advice there was not offered.
One of Visa’s leaders on the encryption and tokenization debate is Jennifer Fischer, a Visa senior business leader. Fischer said scope issues eventually would be worked out. But she cautioned against retailers putting too much faith into, well, anything. “We don’t want encryption to be viewed as a silver bullet. Both encryption and tokenization may enable a merchant to reduce their scope.” A journalism professor once drilled into my head to never use a phrase containing the verb “may” if it could just as accurately be changed to “may not.”
(Related story: PCI Columnist David Taylor offers his own take on the Visa report. Is it a tacit endorsement?)
In another nod to the psychologist analogy, the Visa document tried to sound sympathetic to the plight of retailers while avoiding offering any concrete guidance. “The implementation of any Data Field Encryption must be done in a strong and secure way to prevent the compromise of card data.” (As Harvard Law Professor Arthur Miller once quipped when presented with a similar truism: “Do you actually get paid for giving answers like that?”) The sympathy came in the next line: “With industry standards still in the development phase, that goal can be particularly challenging.”
One of the key issues behind tokenization is the optimistic claim that tokens—properly maintained—might be considered out of PCI scope. Although the Visa document didn’t explicitly say whether tokens could ever be out of scope, it hinted that this possibility is unlikely. “No single technology can completely solve for fraud. Accordingly, Visa views Data Field Encryption as a complement to, rather than a substitute for, PCI DSS compliance requirements.”
It’s hard to see how tokens—as currently envisioned—could ever be considered out of scope given the fact that they start out as card numbers and can—at whim—be converted back into card numbers. Most tokens can’t be unencrypted or reverse-engineered per se, but lists are maintained to permit the token to be re-associated with the original card data. So if it starts out as having all of the data and can again have all of the data at the whim of the retailer, it seems difficult to envision how tokens could be beyond Visa’s or PCI’s jurisdiction.
George Peabody, the director of the emerging technology advisory service at Mercator Advisory Group, pointed out another concern associated with tokenization. Although much of the debate today is focused on whether tokens should be maintained by the retailers directly or sent away where a third-party vendor can handle the protection, the token approach can handle a lot more data than simply payment codes. For convenience, such tokens could also store and protect “all of the metadata surrounding the payment,” including SKUs, time of purchase, shopping history, what coupons or discounts were used and many other CRM details, Peabody said.
“Enterprise security people need to be thinking about what’s adequate when they’re judging tokenization vendors. They better be looking at what is convenient and what isn’t,” Peabody said. Presumably, a retailer that is using a vendor to store and protect the tokens outside of the retailer’s network would want to keep nothing in the token beyond the critical payment details, making sure that SKU and other information is not there. But if the chain is handling such tokens internally, it could be very efficient to use the token techniques to consolidate lots of helpful details.
But here’s the danger with such a scenario. If a retailer chooses initially to store the tokens itself and then, perhaps a year or two down the road, opts to outsource, will the team remember to go back and strip away all of the non-payment data? Will anyone bother? It’s a huge risk, because the tokenization vendors are also likely working for some of that chain’s largest rivals and those retailers also have the ability to access that data. Is that not a huge temptation? How much would an unscrupulous Rite Aid manager pay for access to that kind of CRM data about Walgreen’s customers? It only takes one debt-ridden employee of that token vendor to enable such a nightmare scenario.
October 8th, 2009 at 12:34 pm
The best practices for data field encryption announced by Visa work toward developing a standard approach while offering guidance to payment solution providers. As Schuman points out, the document rehashed conventional wisdom and long-standing Visa and PCI best practices. However, there is definite value in the fact that Visa is actually weighing in and looking to provide some guidance. The five key implementation objectives outlined in the document provide some validation to tokenization approaches that are currently in production. Likewise, their stance that no single technology can completely solve for fraud has merit. Existing solutions that use both end-to-end encryption to encrypt card data from the point of sale, and tokenization on the back end of the transaction support their stance.
October 11th, 2009 at 5:11 am
Does VISA realize that lawsuits are coming and psychologists don’t get sued? I believe both of the following almost contradictory statements:
1. Customer submitted credit cards are radioactive and they need to be immediately encrypted as they are swiped.
2. Data centers that store data-at-rest can be designed to automatically identify and block breach attempts. Database encryption and the associated key management headaches are unnecessary.
Michael Cherry, Cherry Biometrics Inc.
Vice Chair, Digital Technology Committee
National Association of Criminal Defense Lawyers