Fighting Words: Why PCI’s Token Group Blew Up
Written by Evan SchumanAugust 17th, 2011
The PCI group working on the Council's tokenization policy got so embroiled in infighting that it had to be restructured by the Council, according to one participant, which mostly explains the year-long delay in the Council's tokenization policy. But this is hardly surprising, given that the group is mostly employees of competing security vendors—almost all of whom are trying to skew the Council's policy to benefit that vendor's approach.
The token guidance that the group and the PCI Council staff ultimately released on August 12 was a classic compromise, in that it pleased few in the group but was a huge step forward for retail security. The purpose of such guidelines is not to get so specific that it benefits any vendor, but to give instructions to QSAs and retailers on what is permissible and what isn't. Reaction to the document has fallen into these two camps: one saying that the document was not nearly specific enough and is passing the buck to QSAs, and the other saying that this guidance represents major progress and that it should be applauded.
This Story Is Only Available For Premium Subscribers. Click Or Login In Below To Read The Rest Of This Story.
Already a Subscriber? Login Here
Pages: 1 2
3 Comments | Read Fighting Words: Why PCI’s Token Group Blew Up
Leave a Reply
Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
-Christine
August 18th, 2011 at 4:04 pm
Tokenization of data can be accomplished in many ways. Not all security vendors approach the tokenization use case in the same way. The disagreements sometimes focused on the exclusion of one method of tokenization in favor of another, while most of the true security vendors wanted to make sure that all valid and secure use cases were allowed. The Council’s goal is not to endorse one vendor or technology over another and while the tokenization guidance document isn’t perfect it does provide the right amount of guidance for QSAs and acquirers to move forward with scoping decisions as it relates to PCI DSS and tokenization.
August 19th, 2011 at 8:09 pm
I agree with Marc – it’s important to recognize all the hard work that was put into the creation of the document which is a fair and reasonable representation of how a particular technology can be applied to help manage part of an overall risk problem – including inherent risks in tokenization itself in all its forms.
There’s no silver bullet for compliance and risk reduction – and the truth is that many players had been claiming near-utopian scope reduction in the absence of actual security proofs, hard evidence, and without any statements from the PCI SSC – creating a widening gap between expectation and practice. So now a very reasonable and fair document has been published, there should be no surprises that some prior claims don’t match the reality.
All things considered, the working groups and task forces were cordial engagements with a common goal – and despite competitive interests the outcome is a positive and useful one that the industry needed. I say thanks to all who contributed many hours of effort, and look forward to future guidance in a similar vein.
August 22nd, 2011 at 11:31 am
The original definition of tokenization was that a token was not mathematically related to the data it was protecting — the PAN. When the definition was changed in the SIG to accommodate various vendor solutions that didn’t follow this definition, that is where the security holes were introduced. Some vendors were marketing “tokenization” even though their solutions were not using true tokens and were instead using encryption and hash techniques to generate “tokens” — which in turn changed scoping aspects of the concept. To plug the security holes introduced by this definition change, the document simply offloads scoping concerns off to the acquirers and Card Brands, which will in turn refer merchants to QSA’s. In my opinion they took a simple concept that was secure, changed the definition, and then added a “use at your own risk” clause.