New PCI Edict: Tokens Can Be Out-Of-Scope

The PCI Council on Friday (Aug. 12) will, for the first time, offer guidance on tokenization—guidance telling retailers most of their systems can, indeed, be considered out of PCI scope if they properly use tokens. But the Council stressed that if the token is ever reversed into card data on the retailer's systems, everything is fully back in scope.

"There has to be recognition by the merchant that reversing that [token] and being able to again see the primary account number (PAN) and be able to use and execute against account data brings those systems back into scope," said PCI Council Chief Technology Officer Troy Leach.

Leach added that the biggest token-related mistake he's seen retailers make is enabling the data to be de-tokenized during chargebacks, refunds or for loyalty tracking. "That's probably the oversight we see most often: not recognizing back channels where the merchant still may receive that account information."

"To be considered out of scope for PCI DSS, both the tokens and the systems they reside on would need to have no value to an attacker attempting to retrieve PAN, nor should they in any way be able to influence the security of cardholder data or the cardholder data environment," the guidelines say.

The new details also reinforce that authentication data—such as magnetic stripe data or its equivalent on a chip, CAV2/CVC2/CVV2/CID data and PINs/PIN blocks—as opposed to customer data, cannot be tokenized because it would violate PCI DSS Requirement 3.2.

The Council is pushing retailers to combine token efforts with point-to-point encryption, a combination that could temporarily enable retailers to safely experiment with mobile-payment systems and still be PCI compliant.

Many of the new guidelines should not surprise veterans of tokenization. For example, an emphasis on the need for all of the systems associated with tokenization—including data vault, segmentation, monitoring systems, cryptographic key storage and token mapping—to be fully secured. "PCI DSS requirements are not completely eliminated," Leach said. "There are elements that still would need to be validated."

Council officials also pointed to the radically different way various vendors handle tokenization and to the fact that, logically enough, the rules should be different for each. "There is really no standard for any of these solutions at this point," said Bob Russo, the Council's general manager. "For the token to be considered out-of-scope in PCI DSS, the token's got to be unusable if the system it resides on is compromised." Added Leach: "Not all algorithms are created equal."The guideline itself says that token programs "do not eliminate the need to maintain and validate PCI DSS compliance, but they may simplify a merchant's validation efforts by reducing the number of system components for which PCI DSS requirements apply. Verifying the effectiveness of a tokenization implementation is necessary and includes confirming that PAN is not retrievable from any system component removed from the scope of PCI DSS."

Typically, tokens merely replace the storage of sensitive card information. But some approaches enable the token to, theoretically, be able to make transactions directly. If that's the case, it needs additional safeguards. Indeed, such transaction-capable tokens may thrust that chain right back into PCI scope.

"An important consideration when evaluating tokenization is whether the token itself can be used in lieu of cardholder data to perform a transaction. Tokens that can be used as payment instruments (sometimes called high-value tokens) could potentially be monetized or used to generate fraudulent transactions, and may therefore have the same value to an attacker as the data they are intended to replace," the guidance says.

"Tokenization [packages] that support these types of tokens should have additional controls in place to detect and prevent attempted fraudulent activities. Additionally, tokens that can be used to initiate a transaction might be in scope for PCI DSS, even if they cannot directly be used to retrieve PAN or other cardholder data. Merchants should therefore consult with their acquirer and/or the payment brands directly to determine specific requirements for tokens that can be used as payment instruments."

The guidance also gets very specific about how tokens would have to act and be used to keep a retailer out of PCI danger. "Recovery of the PAN value associated with a token must not be computationally feasible through knowledge of only the token, multiple tokens or other token-to-PAN combinations. The PAN cannot be retrieved even if the token and the systems it resides on are compromised."

Another key out-of-scope issue deals with the reversible-encryption token approach, which the Council document describes as one "where the token is mathematically derived from the original PAN through the use of an encryption algorithm and cryptographic key." In those instances, the document says, "the resultant token is an encrypted PAN and may be subject to PCI DSS considerations in addition to those included in this document. The PCI SSC is further evaluating how these considerations may impact PCI DSS scope for reversible, encryption-based tokens."

The report also encourages retailers to have a precise method to distinguish between tokens and actual PANs.

"Without the ability to distinguish between a PAN and a token, the merchant or service provider may not realize that the tokenization system isn't functioning as intended. Additionally, PANs could be mistakenly identified as tokens, which can lead to mis-scoping of the CDE and the possibility that PANs are left unprotected and open to compromise," it says. "Note that some tokens are designed to mimic the type and format of the original PANs, and it may not be possible for a human reviewer to distinguish between the two types of data. In this instance, a specific tool may need to be utilized or a function performed to verify that an alleged token is actually a token and not a PAN. The mechanism or method for distinguishing between tokens and PANs for a particular tokenization [approach] should be shared with the merchants using that [token application] to allow merchants the ability to verify that their CDE has been accurately defined and scoped."Like any security application, IT management of tokens must consider that cyberthieves are going to be constantly updating their attack methodologies, especially when tokens become more popular and, as a result, more profitable targets.

"If a token is generated as a result of using a hash function, then it is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of the PAN," the guidance says. "Where hashed and truncated versions of the same PAN are present in the environment, additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN. Because it contains PANs as well as tokens, the data vault often presents the most attractive target for attackers. Compromise of the data vault could potentially result in the compromise of the entire tokenization system, and additional security controls above and beyond those required in PCI DSS may be warranted."

A token strategy will also change retail contractual issues and bring in a new player—the token vendor—to the security mix.

"Some PCI DSS requirements will apply to the merchant even when a tokenization [approach] is outsourced or hybrid. For example, PCI DSS controls apply wherever PAN is processed, stored or transmitted—such as at the point of capture—as well as at any de-tokenization points. Additionally, the merchant is required to implement and maintain policies and procedures to manage service providers whenever cardholder data is shared," the guidance says. "Ensure that proper contractual agreements are in place, with the tokenization service provider acknowledging that the service provider is responsible for the security of cardholder data processed, stored and/or transmitted by the service provider. Review logs of the merchant's interaction with the tokenization systems and processes on a regular basis to ensure that only users and system components authorized by the merchant have access to the tokenization/de-tokenization processes."

Another line should probably be added to contracts, one addressing the fact that the token vendor "supports the assignment of PCI DSS responsibilities between the [token vendor] and their customers. For example, the solution should not return PANs to a customer without the customer's express permission and acknowledgement of how this action might affect the customer's responsibility for securing cardholder data and for validating PCI DSS controls."