Going Out On A Limb With Out Of Scope
Written by Walter ConwayNovember 18th, 2009
This week marks the debut of StorefrontBacktalk's new PCI columnist, Walter Conway, and Conway debuts by trying to decipher encrypted tea leaves of the PCI Council's position on out-of-scope data. what does “the means to decrypt” include? We need, as always, to look at the Council’s intention and not just dissect its words. Although this sentence was followed by a discussion of who manages the encryption keys, I believe the Council intends “decrypt” to mean any way to get from encrypted or tokenized data (i.e., out of scope) to plain text data (i.e., in scope).
That includes gaining access to the keys, but it also includes access to token lookup tables or any other way to get back to the original data. That means you need to be just as concerned with social engineering attacks, malicious insiders and phishing as you do with hackers stealing encryption keys.
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
5 Comments | Read Going Out On A Limb With Out Of Scope
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? 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? 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.
-Ed
November 19th, 2009 at 12:51 pm
I would argue that “true tokens”, meaning tokens not based on the PAN, are out-of-scope and that the PCI council or the card brands would have a difficult time bringing them in-scope. Reason being, true tokens can be generated based and any scheme: simple sequential numbers, pseudo random numbers, timestamps, or unlimited other factors. Prior to “tokenization” (and still to this day), a POS vendor could use the invoice number as a “token” with the gateway that I represent. If tokens are deemed in-scope, shouldn’t invoice numbers as in scope as well?
On the other hand, I would argue that “false tokens”, meaning tokens based on the PAN whether a hash or encryption, are in-scope because they would have the potential to be looked up via a hash table or decrypted.
In either situation (true or false tokens) the tokenization system itself would always be in-scope.
November 19th, 2009 at 8:06 pm
Thanks for your comment, Steve.
While “true tokens” as you call them can’t be unscrambled, there is generally a lookup table or some other method to get back to the original PAN. That lookup table is the source of the vulnerability, and that vulnerability increases based on your policies/procedures for who can get to it and, thereby, the clear text data.
If there is no table or similar way to get back to the clear text data, then I would agree the “tokenized” data are out of scope. But I wonder how much such “true tokenization” would reduce scope in practice. That is, it seems these “true tokens” would not be much use for exception item processing, velocity tracking, loyalty, etc., so you would still need to keep and protect a lot of PAN data.
We agree that the tokenization system would always be in scope, which is why tokenization is a great way to reduce scope, but it doesn’t make PCI go away.
November 20th, 2009 at 12:50 pm
Not all tokenization solutions are created equal and I would agree, if a lookup table is used, scope (specifically out-of-scope) becomes questionable. My initial thought is the lookup table you referenced would not be part of a “true token” solution.
I only know the inner workings of our tokenization solution and there is no way to use the token to get back the PAN — the token can be used by the merchant to process transactions, but the PAN is never returned to the requestor (and tokens can only be used within the merchant it was issued).
Now I do know of at least one solution where the token is used to retreive the associated PAN, but even in this solution I would consider this a weakness of the tokenization solution; nothing to do with the scoping question of application that use tokens.
November 20th, 2009 at 1:15 pm
You make two important points on which we agree, Steve. First, when you say “Not all tokenization solutions are created equal”, and I place emphasis on the “proper implementation” of the tokenization (or any security) product, we are saying much the same thing. Whether the product or the implementation (or both…shudder…), you need to look at the details.
Secondly, you point out the situation where “the PAN is never returned to the requestor.” So long as this is enforced, and so long as the vault/entity remains PCI compliant (and maybe stays in business, too…) and you can prove that the practice meets the policy, I may well agree with you that the tokens could be viewed as out of scope.
November 20th, 2009 at 1:47 pm
You both make good points, but …. I think the key takeaway is housed in Walt’s last comment: “I may well agree with you that the tokens could be viewed as out of scope.”
I stress “could be viewed as” and would argue that all of this–I was about to say “much of this” but it’s really almost all–hangs on what the viewer (presumably the PCI Council, the card brands, some major issuing banks, key assessors or some combo of all of the above) decides to do. And for most of the players mentioned above, the only safe route is to to be conservative and declare that anything in doubt is in-scope. You can make the compelling and legitimate case in the world, but the viewer doesn’t feel like extending the risk, it won’t go anywhere.
And from the retailer’s perspective, why should they take their own risk and treat data dubbed out-of-scope any differently? It all hangs on somebody putting faith that an out-of-scope declaration gives them carte blanche to treat data differently. I doubt many wise viewers (assessors, PCI, brands, etc. OR retail IT) would find it worthwhile to take that risk. As for the merchants, they’ve learned the hard way that safe harbour is a myth. How many chains have been declared compliant but then been reversed after a breach? And you expect these people to trust an out-of-scope declaration?