Avivah LitanTokenization is a very hot topic among Gartner clients who have to comply with PCI DSS. After all, by not storing electronic cardholder, ‘most’ enterprises are eligible for a greatly reduced set of PCI requirements as contained in SAQ (Self Assessment Questionnaire) A, B or C.
The problems with tokenization are many but they don’t come close, in my opinion, to outweighing the benefits. (Please see our recently published Toolkit “Checklist of Tokenization of Card Data for PCI compliance). The biggest problem, in my opinion, is the lack of standards for tokenization, meaning that if you tokenize using one vendor’s solution, you’ll have to ‘retokenize’ with any replacement vendor solution that you may eventually switch too. That’s not too big a problem however, if you choose a vendor with a sound methodology and track record. For now its up to the implementing enterprise to determine what constitutes a sound methodology.
So what are the ‘authorities’ up to that will help standardize and formalize the strong trend toward tokenization?
Visa recently published a draft of its “Best Practices for Tokenization” Version 1.0 and solicited stakeholder feedback and comments by August 31. Lots of people have issues with the draft; I’m not one of them. Maybe I’m reading a different draft. It’s pretty basic and doesn’t help or hurt much. I think its main (positive) attribute is that it formalizes recognition for tokenization as a viable method for securing cardholder method.
The PCI Security Council on the other hand hasn’t come out with anything formal yet on tokenization and won’t be doing that any time soon. (I don’t expect anything on it in the updated PCI DSS standard coming to us this Fall). They’ve left that to a Special Interest Group (they also have SIGs that look at EMV/Chip, and point-to-point (a/k/a end-to-end) encryption). The SIG has no deadline for coming up with anything on tokenization but likely will publish something on it by the end of 2010. Is that going to offer practical advice? Probably. And that’s a good thing but it will simply be guidance – not an enforceable standard.
More importantly, the simplicity of the SAQ process is about to end and that will make the rewards of tokenization (a greatly reduced audit) not as easy to achieve. The PCI council is planning to come up with a Q & A that each card acceptor (e.g. retailer) fills out to describe the card acceptor’s card handling environment. And out will pop a customized SAQ tailored for the card acceptor’s/retailer’s environment. Again, there is no deadline or deliverable date for this revised SAQ process but I expect it to happen within 12 months, and probably much sooner. I also expect it will be done in phases with incremental additions and changes to the SAQ process starting with the release of the new PCI DSS standard this Fall.
Bottom Line
Presumably if you don’t store data, you don’t have to protect data at rest. So hopefully we can count on that continuing. But data at rest for PCI compliance purposes will probably come to mean (and has already come to mean) data stored in memory – even for a fleeting moment – so watch out for the nuances.
Life and PCI compliance is not going to get easier. It’s probably going to get harder and more complicated when it comes to implementing tokenization in order to reduce the scope of PCI audits. It’s still worth undertaking but with so many cooks in the kitchen, expect a rougher ride.
Category: Uncategorized Tags:
12 responses so far ↓
1 Walt Conway August 5, 2010 at 11:48 am
The part about the end of the SAQ process is certainly news to me. I know the Council and Bob Russo in particular have acknowledged there are problems with the present SAQs, but I didn’t anticipate their being replaced completely. I have to wonder whether the Council will host this Q&A site (for 11 million merchants?) or if QSA companies will or…?
2 Ulf Mattsson August 5, 2010 at 12:46 pm
Avivah,
Good point on the need for industry standards and thanks for taking a leadership position on Visa’s tokenization strategy document since this is a very important issue. While I applaud Visa for making what is overall a very positive move, my view is that they may have rushed this document to publication and, in the process, ignored several key issues.
Visa implies a “one-size-fits-all” architectural solution that in many ways exemplifies the old approach to tokenization vs. today’s approach. The difference is significant and underscores just how much tokenization has evolved in recent years.
All old tokenization solutions are based on the simple concept of a large and dynamic table of token/credit card pairs. While this is an obvious and reasonable approach, it has its disadvantages and issues with respect to performance, scalability, and availability. The core obstacle with the traditional tokenization approach is that the token lookup table is so large and dynamic that it’s hard to manage. Solving the availability and scaling needs of large enterprises requires the complex replication or synchronization of the token tables.
New distributed tokenization approaches, on the other hand, simplify and eliminate performance, scalability and availability issues. New tokenization is able to pre-generate static token tables that can be installed in multiple locations. There is also no need for real time synchronization or replication. New tokenization can perform over two hundred thousand transactions per second on a small configuration. This is the approach being implemented by major credit card companies and retailers today. The Visa Best Practices document simply does not take into account issues with performance, scalability and availability that we are all aware of today.
Take, for example, Visa and their requirement for Token distinguish-ability. This requirement is quite logical because real problems could arise if it were not possible to distinguish between real card data and tokens representing card data. This requirement does, however, complicate systems that process card data. All systems would need to be modified to correctly identify real data and tokenized data. These systems might also need to properly take different actions depending on whether they are working with real or token data. So, although a logical requirement, it’s also one that could cause real performance issues.
In addition, Visa’s position is that it’s the responsibility of the tokenization system to determine when the data should be sent tokenized or clear-text. I believe this should be the responsibility of the data management system, of which tokenization is a key feature/subset.
Finally, in terms of the single and multi-use issue, the multi-use case seems like an accident waiting to happen. There are better ways to secure PAN data than encryption or hashing. I think the best path is to simply use a random assignment or number. If the output is not generated by a mathematical function applied to the input, it cannot be reversed to regenerate the original PAN data. The only way to discover PAN data from a real token is a lookup in the token server.
Ulf Mattsson,
CTO, Protegrity
3 Tweets that mention What’s in store for PCI DSS and Tokenization -- Topsy.com August 5, 2010 at 4:28 pm
[...] This post was mentioned on Twitter by david campbell and Secure POS, OWASP303. OWASP303 said: RT @SPVA: Industry News: @Gartner_inc on What’s in store for #PCI DSS and Tokenization: http://ow.ly/2lyIV [...]
4 Avivah Litan August 5, 2010 at 11:12 pm
Good points Ulf. I hope you present them to Visa as part of their request for comments.
5 Avivah Litan August 5, 2010 at 11:17 pm
Walt: perhaps they will just create a dynamic form that the retailers and card acceptors can download and run themselves. This certainly seems to translate into more work for assessors though.
6 Bruce Sussman, CPA, CISA, CISSP, QSA August 8, 2010 at 3:46 pm
I read with great interest Ulf’s comments on the issues with the scalability and response time associated with tokenization look up tables. A valid issue but has anyone thought about the utility of hardware based security modules (HSM)?. HSM, commonly manufactured by Attalla, Thales, Futurex etc, long ago solved the security and response problem for the ATM industry. Every time you swipe your card at an ATM, the encrypted pin block is sent to an HSM, Within seconds, that encrypted pin block is stripped of its encryption,issuer/acquirer information extracted and re encrypted.
I see the tokenization data path as same problem, same solution. HSM’s can be scaled down in size to fit the necessary economics. The problem, however, was solved long ago.
7 Stephen Wilson August 8, 2010 at 8:12 pm
I fear that the total cost of tokenization in complex merchant environments is underestimated. Substituting PANs with random tokens seems a clever work-around to get cardholder data out of merchant systems, but it’s far harder than it looks.
A colleague told me about a tokenization project at a very large retailer in Asia. They had several different billing systems under one roof, some with very old legacy code. The software analysis stage alone for integrating tokenization took well over 100 working days effort. For such an apparently elegant solution, this complexity is shocking me! Implementation required identifying and remediating all points in the legacy systems where changing from numeric to alphanumeric data formats upset the software. These cases were more widespread than anyone first thought; some database tables were known to expect purely numeric formats, but there were also odd points where old COBOL code simply choked on unexpected data types. Some billing modules were out of maintenance contract and needed to be replaced in their entirety, and *then* tokenized. This added unbudgeted costs to the PCI compliance program. Also there were impacts on routine management reports and call centre processes, and substantial staff training was entailed. The last I heard, the software change process was ongoing six months down the track and costs had more than doubled from initial estimates. My colleague estimated that the implementation cost was ten times the price of the tokenization software and hardware itself.
So let us all reflect on the true deployment cost of tokenization. Why should it all fall on merchants like this? It’s not their fault that stolen PANs are valuable to criminals who can clone them onto fake cards, or replay them at CNP sites. The flaw in the billing system that enables most card fraud is very specifically the replayability of account data via cloned cards and bogus Card Not Present transactions. If PANs weren’t so easily replayable, they wouldn’t be targeted by ID thieves, and they wouldn’t represent such a risk when collected in merchants systems.
Tokenization is a magic trick with large hidden costs, which serves some narrow interests by artificially boosting PCI compliance — a gambit that doesn’t necessarily reduce fraud across the system anyways. Neither tokenization nor PCI-DSS compliance solve the fundamental problem that stolen PANs are gold to criminals. I’m sure the total cost would be less if we addressed the card fraud problem at the precise points of failure: the terminals, and the e-commerce servers accepting CNP payments (where asymmetric cryptography can tell stolen PANs from originals).
8 Sue Zloth August 9, 2010 at 5:22 pm
Avivah, I agree. Tokenization is on the mind of most. VISA’s guidance is a first step, but we expect that the PCI Council will also implement guidance on this issue as well.
In fact, I am a member of the SIG that you mentioned in your post. We have been given clear direction by the PCI SSC Board of Advisors to get our recommendations to the PCI Technical Working Group (the group that works on the details of the standards) in time for the TWG to determine if they will include scoping updates in the October release.
We see that as a step in the right direction.
9 Avivah Litan August 9, 2010 at 9:12 pm
Stephen – you raise good points. I wrote a case study on a project that implemented tokenization and there were all kinds of issues such as the ones you mention. It still paid off for this company however (NCR) but I can see how it could easily tip the other way. Also I often hear about problematic tokenization projects, mainly because of immature vendor solutions. But given the right project management, realistic expectations, a suitable environment (i.e. not too many exceptions) and a mature vendor solution – I have also seen tokenization pay off big time.
10 Avivah Litan August 9, 2010 at 9:14 pm
Sue: thanks for the input. Glad to hear you are on the SIG and that the timeline is indeed escalated and that there may be references to the work in the October release. I’m sure a lot of folks will appreciate the work and hope that the Council and the card brands will give it the attention that it needs. You are right – it’s a step in the right direction. we need more of those…
11 Avivah Litan August 9, 2010 at 9:53 pm
Bruce: I’ve often thought about applying HSM solutions to PCI-related problems, e.g. point to point encryption or tokenization. Not sure why they aren’t being considered. Good question.
12 “Best Practices for Tokenization” – some thoughts on token generation August 13, 2010 at 12:19 pm
[...] in it. I won’t repeat it here, but for example the comments in Avivah’s post here speak for themselves: there are a lot of different aspects to [...]