Going Out On A Limb With Out Of Scope
Written by Walter ConwayA 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.
The PCI Council has said that encrypted cardholder data “may be deemed out of scope” in some circumstances. Although these words sounded reassuring to some, IT execs need to read the Council’s statement carefully. IT’s implementation of encryption and tokenization technologies may cause out-of-scope data to quickly morph into in-scope data.
Last week, StorefrontBacktalk Editor Evan Schuman argued that, practically speaking, there may be no difference between how you should protect in-scope and out-of-scope cardholder data. I share his frustration, and I generally agree with many of his conclusions. Maybe what we need is a third designation: temporarily out of scope.
The Council already accepts this concept of temporarily out of scope data in cases of cancelled, fraudulent, or stolen cards. Some retailers feel it’s safe to use these PANs for testing and they consider them out of scope. The Council has a FAQ stating: If the issuer confirms the cards are inactive or disabled, the PANs no longer pose fraud risk to the payment system. The PCI DSS would not apply in these cases. If, however, the PAN is later reactivated, PCI DSS will again apply.” What was once out of scope can quickly become in scope, and therefore I discourage my clients from storing inactive or disabled PANs.
This discussion has very real implications for IT execs (budgets, policies, procedures) and encryption and tokenization vendors (their business case). In a posted FAQ, the Council asked itself: “Is encrypted cardholder data considered cardholder data that must be protected in accordance with PCI DSS?” And it answered: “Encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.” Let’s focus on two questions that arise from that sentence.
The first question is, 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.
The second question is what constitutes an “entity”? Does it have to be a third-party? Could an entity with the means to decrypt cardholder data be a subsidiary of your company and, if so, is that data still considered out of scope? If it’s not a subsidiary, can your company have a partial ownership stake in this entity? Is there a test for an entity’s independence? Could the entity be your nephew, Jimmy? One thing an entity does not include is segmentation, which is already an implied part of PCI DSS.
Don’t expect a definitive answer from either the Council or the brands as to whether you could have a subsidiary (rather than a third-party vendor) with sufficient legal and operational separation to meet the Council’s intent. If you are thinking of pursuing this course, you need to examine the particular circumstances and discuss it with your QSA as well as maybe a couple dozen lawyers.
The PCI Council’s FAQ concludes by reminding merchants to “be aware that encryption solutions most likely do not remove them completely from PCI DSS.” The Council is saying that neither point-to-point encryption nor tokenization is a panacea. Silver bullets have been outlawed. These technologies are designed to limit your PCI scope not necessarily to eliminate it. Even in the most optimistic scenarios, you still have legacy applications as well as key-entered (POS or MOTO), e-commerce and call center transactions where people, computers and sometimes paper exist along with all that messy in-scope cardholder data. Realistically speaking, as long as you take plastic, PCI DSS applies to you. With apologies to the diamond industry, “PCI is forever.”
-Marc
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?