Going Out On A Limb With Out Of Scope

Written by Walter Conway
November 18th, 2009

A 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.”


5 Comments | Read Going Out On A Limb With Out Of Scope

  1. Steve Sommers Says:

    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.

  2. Walt Conway Says:

    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.

  3. Steve Sommers Says:

    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.

  4. Walt Conway Says:

    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.

  5. Evan Schuman Says:

    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?


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 60,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.