The Falcon's View

I approach this comment very humbly as I believe you probably have done much more research on this topic than I. With this, I believe the purpose of tokenization is to 1) reduce risk to the customer’s environment by eliminating as much CC data as possible, and 2) to reduce the impact PCI has on an environment by shrinking the scope. Based on what I know of tokenization, it is no silver bullet, but it does achieve both goals above.

Ultimately, like you, I would like to see that silver bullet for removing all CC data from our client’s environments.

@Alex -

I think you're right, I just question whether or not it's achieving either of those objectives. Too often I see orgs with multiple billing systems and I wonder, will the tokenization solution just become yet another layer of complexity in an already over-complex environment?

In terms of shrinking the scope, I'm not fully convinced it actually achieves that goal. If it's a 1-to-1 match for an existing billing system, it's simply a shell game, moving the CC data from one box to another. Most solutions are built on the premise that your flows don't change, which means your PCI scope very likely stays almost exactly the same. Not much gain there.

Thanks for the comment!

-ben

Nice debate topic. The root issue is PCI Scope, as "defined" by QSA's who may or may not fully understand security or the merchant or enterprise IT environment. If anyone has attended QSA training they would see the gaps emerge quickly in knowledge levels which vary from industry hardened experts to extremely inexperienced technicians who lack basic infosec awareness. Hence we have the drive to scope reduction over risk management - that is, if scope can be easily pinned down :)

One of the reasons Tokenization has taken off is that it permits merchants to side step a lot of PCI DSS because tokenization is not defined specifically in the PCI DSS Standard. This is bound to change, but right now it is more difficult to assess Tokenization as “correctly” implemented or not by a QSA - there's no guidance, no “Section 3.X – Tokenization Requirements”. Defining what "cardholder data" is also a grey area in PCI and debate rages. QSA's are trained that encrypted cardholder data is cardholder data – a bizarre circumstance to anyone who's experienced in encryption and key management- and which seems to be missing the critical overlooked addendum "if there is explicit access to the specific encryption key used to encrypt the cardholder data". However, this seems to have come about as breaches from badly implemented systems have taken place – e.g. putting your keys in the same database as the encrypted data, encrypting with a key left sitting unprotected in a store controlled that anyone can then copy. Bzzzt! Danger! But was the encryption itself bad? No ? Was the key management bad ? Yes. So why not reduce scope with encryption one asks? Well, true end to end encryption will do just that - from swipe to acquirer /processor for example (not to be confused with Point to Point...but thats another topic).

Tokenization on the other hand leverages the grey area of the standard and thus creating the concept of the "disassociated" data item - the token - which can therefore be used to reduce scope – at least for now. This is also missing the critical addendum "can reduced scope if and only the entity who owns the token cannot easily detokenize to clear data, the token is not reversible itself or weakly constructed, and does not retain a 1:1 relationship to live data or permit replay attacks in token dependent systems as a means to defraud systems". Such reversibility with an token service or an in house solution may be a simple phone call or dispute requests, or accessing a weakly managed service API or an in-house database and/or its API. I've heard so many QSA's talk as though Tokenization is "stronger" than encryption without fully understanding either: Quite alarming - both from what may have passed as "compliant", and the level of knowledge in stating such. Both Encryption and Tokenization have their place, and the format preserving encryption approaches can essentially provide the benefits of Tokenization without the ugly massive token lookup database that still has to be managed by someone, somewhere.

The challenge is the PCI council created a clarification FAQ note on scope and encrypted data, but the way the answer is described is still unclear. Tokenization is yet again not mentioned in the same way, and the encryption model the clarification is based on looks upon the problem of scope and encrypted data from an assumption that keys are merely dished out to people. A modern cryptographic approach perhaps involving hardware key management and public key techniques eliminates this – but this fact seems to be lost in the confusion and we have the mantra: encrypted data is cardholder data, again without analysis, logic, or reason.

My view is that scope and Tokenization will change in 2010. Oddly, despite encryption being a very mature technology and with care can be implemented extremely well, it comes under more scrutiny for correct implementation in PCI DSS because the risks of use and implementation are well known and can be tested, managed, and controlled - hence the is "in scope".

Taking a regulation side-stepping approach is short lived. This is especially true if by tokenization, all one is doing is becoming an issuer of a "number" that has a local 1:1 mapping to live data which represents value. How is that descoping? Its making a previously insecure entity an "issuer" of a proxy card number....just as you noted, billing, booking, forward reservation systems can make active decisions based on the proxy…and thus open that to potential abuse, without even knowing a live credit card number - by proxy if you will.

Tokenization also suffers from a widely varying range of implementations and indeed scale/security problems – that big database is going to get bigger. Some Tokenization approaches are good and some scarily bad and insecure – e.g. using poor hashing techniques to create tokens without about as much strength as 30 bits of encryption, or describing techniques which hide the fact that encryption is used up front to get the token in the first place - and sadly an almost implicit assumption of reducing scope from many QSA's without detailed analysis or risk assessment of exactly why. To them, Token = out of scope, end of story. Bzzzt! Danger!

As scope reduction reduces QSA costs, the drive towards it is economic vs risk driven: a short term benefit, but without care a potential long term disaster. Thus, I expect as both the quality/experience of the QSA's improves and the PCI Council moves to the new standard in May 2010 its likely in my opinion that Tokenization will come under more intense scrutiny and potentially some form of standardization and guidance.

Those rare but very experienced QSA's that really know IT risk and payment processing environments and truly help in managing risk already know this. However, time will tell and hopefully logic and best practice will prevail to deliver the original intent of PCI – reducing risk.

-Mark

I've been reading up on tokenization since my current employer utilizes it (not for credit card info as far as I know, but for other reasons). Everything I've read has left me (not an InfoSec expert by any means, and more and more I'm learning what I don't know) thinking, "I don't really see how that's much better, since 1) Someone still has to secure the user info, and 2) now someone has to be responsible for and secure a database where the tokens can be mapped to real data."

Somewhere on this page the term "shell game" was used. That's exactly what it is ... and if the shell game isn't played well (and considering the players involved, one would guess it might be no better than the "original game" they were playing), tokenization doesn't seem to gain much.

At the very least, encryption shouldn't become ignored when using tokens - they should be used together.

It may not be "as dangerous" for (an unauthorized) someone to have the token as it would be for them to have the actual information ... but it still seems dangerous to me. So they have a little more work to do before they can get actionable data ... that's never stopped them before.