The Dangerous Out-Of-Scope PCI Charade

Written by Evan Schuman
November 12th, 2009

Dominating many discussions over the last few weeks in payment security circles has been speculation over what the PCI Council, Visa and others will decide about declaring some types of data out-of-scope for PCI purposes. Getting much less attention is what IT execs should do with data that is declared out-of-scope and how dangerous a game out-of-scope is.

At its simplest, out-of-scope means beyond jurisdiction; it means that whatever is being discussed no longer falls under the rules and requirements of PCI. One critical problem is that the brands and the PCI Council giveth and they can taketh away. In other words, if you’ve started sharing some, for example, tokenized data with marketing because a temporary out-of-scope ruling makes you comfortable doing so, you may find it almost impossible to undo should that ruling be reversed. Put more philosophically, you won’t likely be able to get the clear-text toothpaste back into the “they’re going to fine me from here to Shanghai, aren’t they?” tube.

The safest route is to somehow identify things that are declared temporarily out-of-scope from those that are permanently out-of-scope. But nothing would likely ever be declared temporary, so that’s rather useless advice. The only wise route is to simply assume that everything declared out-of-scope could later be declared back in-scope.

Standards change, and nothing changes faster than security standards. “We all thought WEP was cool until the data security standard changed,” said Walter Conway, a QSA with 403 Labs.

What’s just about as dangerous as being cavalier with data that may be only temporarily out-of-scope is reading too much into the vague comments coming from various card brands and the PCI Council. Statements have been made hinting that some technologies may be considered out-of-scope.

“If it’s potentially out of scope, I think you’re mad to consider it out-of-scope,” Conway said. “I think you’re juggling razor blades if you treat it as out-of-scope data for PCI purposes.”

Speaking of juggling razor blades, why would IT want to treat data differently if it’s out-of-scope? Just because PCI may not—for the moment—care about it doesn’t mean that various kinds of bad guys might not care quite a bit.

Let’s say you now share those PANs with someone in marketing. And they copy it onto a thumb drive or print it out and stick in a bag to take home.

If out-of-scope doesn’t mean it’s OK to shed security rules, what good is it? The only practical advantage is a cost savings on PCI assessments, to the extent that the newly out-of-scope data represents a material portion of the overall data you need protected.

Tokens are a common target for out-of-scope, but Conway argues that it could prove to be a reckless move. (Tokenization is fine, but assuming it’s out-of-scope could be reckless.) Why? Because anything that could be made unreadable can, in various ways, be made readable again. “Key management is only one way to make something that’s out-of-scope in-scope again. What if someone breaks into the secure vault and steals the key and then comes into your network?”

Another Conway scenario: “The IT staff just picked up a rumor that they’re being laid off and they call and say, ‘Give me these 100,000 tokens for testing.’ You have to ask yourself: My controls, how effective are they?”

Out-of-scope declarations are a great concept, and if they happen and can be used to lower your assessment costs, that’s wonderful. But if you start treating data as out-of-scope, you may find that out-of-scope could drive you out-of-mind.


6 Comments | Read The Dangerous Out-Of-Scope PCI Charade

  1. Steve Sommers Says:

    The out-of-scope argument is very valid but in reference to tokens, the premise of temporarily out-of-scope or abruptly deemed in-scope if flawed. Conway was quoted “anything that could be made unreadable can, in various ways, be made readable again,” this statement is true when talking about encryption technologies (all encryption technologies) but not so with true tokens. True tokens are in no way related to the original data other than as a reference key. The token, or reference key, can simply be a sequential number stamped when the PAN is secured, can simply be a timestamp to 16 or more digits of precision, or it can be based on a random number or any other non-PAN related factor – the key here is that the PAN is not used to create the token. If anyone ever cracks how to “decrypt” a true token, then there will be more money to be made elsewhere because they will have determined how to predict past and future events. I know I would crack a couple of lotteries and you would never hear from me again. ;-)

  2. Evan Schuman Says:

    Good general point, Steve, but for the record, not all tokenization is done the same way. Many tokens are associated with lookup lists that allow for them to re-matched to the card data if it’s needed, such as for a chargeback. A token doesn’t have to be decryptable (is that a word?) for there to be a way to access the original data. At least that’s the case with some tokens.

  3. Kevin Thompson Says:

    True, that someone may be storing a token-to-PAN cross reference. But that would be the bank, not the retailer. If the bank is not sure they can keep their data secure, then there are bigger problems to be addressed than bringing tokens into scope.

  4. Evan Schuman Says:

    But the consumer walks into a particular retail chain, gives their payment card to someone wearing that chain’s uniform and the card is swiped. If, six months later, there’s a breach and that card was misused, it’s the retailer who will in the spotlight. They’re the deep pocket and, therefore, the target.
    If the consumer is angry and wants to cut off business, it will hit the retailer. Therefore, if the retailer is going to end up being blamed no matter what, they have to stay involved.

  5. Mark Bower Says:

    Tokenization and End to End Encryption each have their benefits and use cases in PCI DSS scope reduction.

    However, having the ability to do both Tokenization and End to End Encryption (not mere point to point) can have tremendous scope and risk reduction benefits and agility to adapt to change in this fast moving compliance landscape. Being able to have both on tap from a single platform is a solid approach to avoiding the pitfalls Evan highlights in this article which brings a fresh light to a hot topic – de-scoping.

    In terms of the temporarily out of scope question: for tokens to be useful they must be “de-identified” back to the live data at some point in to permit functions like charge-back, and other in-house PAN dependent functions. For smaller level 4 merchants there may be less of a need to de-identify the token back to a PAN in house. However for Level 1 and 2 merchants there’s a myriad of interdependent in-house systems that will continue to need the PAN even if temporarily. It’s also not uncommon to find large merchants with established relationships with multiple processors – one for Credit, another for pre-paid, another for co-branded Gift cards etc. So, sadly it’s not a simple a case of “removing all PAN data” or moving to Tokenization services; charge-backs are a good example where PAN may be needed, but in-store credit, fraud and velocity checking and other Tier 1 everyday processes are often PAN-dependent and won’t go away any time soon. Indeed, many of the functions are fraud countermeasures that save merchant millions a year are PAN-dependent and cannot easily change.

    As the article points out – one cannot be reckless in trying to avoid scope as the PCI landscape is changing very quickly. End to End Encryption from the POS is emerging as a leading way to reduce scope for merchants as noted in PwC’s summation of their findings – and End to End Encryption implementations like ours have come with formal cryptographic security proofs – assurance of security in protecting data to the strong cryptography requirements of PCI DSS and beyond.

    On the other hand, Tokenization implementations vary substantially per Evans comments above; as a result there has to be additional consideration – where are the formal proofs of security vs mere assertions from vendors, where is the evidence that it is strong and proven? For Tokenization that’s a difficult challenge since there’s no standard to hold up to evaluate to a level of assurance. I’ve yet to see this kind of transparency which is a critical aspect of security best practice – security by obscurity doesn’t fly. That’s in direct contrast to Encryption and Key Management which has 30+ years of rigor and best practice.

    Besides, any Tokenization system must use encryption on the back end to protect the PANs in that mapping system, and data capture or transport encryption on the front end for any offline cases and to communicate to the token service or system – so why not simply encrypt it end to end the first moment ?

    Best Regards,
    Mark Bower
    VP Product Management
    Voltage Security

  6. Steve Sommers Says:

    Most reference to scoping have to do with PCI compliance, not legal liability. Legal liability, for the most part, has one scope — the person with the deepest pockets is liable for everything.

    I agree fully agree with your statement “not all tokenization is done the same way,” and that’s why I have been active lately defending “true” tokenization. With the company I represent, there is no way to lookup the token to get the card number — tokens can be used by the merchant for processing transactions, chargeback defense, posting refunds or future payments, but not downloaded.

    I would argue that if tokens were somehow used in a breach, its not the failure of the token (or any application that used the token) but instead a failure of the tokenization solution. Basically I’m saying that I can’t see any reason or legal basis for a “true” token to be within PCI scope. If tokens are ever deemed in-scope, then where does the line stop? I ask this because it would mean that all timestamps, sequential number, random numbers or any other piece of information that may or may not be used to generate a token is within scope — all data a POS uses and stores, not just payment data.

    Sorry for any typos, it’s late and I’m on my way out the door for a long weekend.


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.