The Dangerous Out-Of-Scope PCI Charade

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.