PCI Council releases tokenization guidance
The use of a tokenization solution does not eliminate a merchant's need to validate compliance with the Payment Card Industry Data Security Standard (PCI DSS), the industry group responsible for managing payment security guidelines said in a new document released Friday.
“The misconception is that I can buy one of these [tokenization solutions] and be PCI compliant,” Bob Russo, general manager of the PCI Security Standards Council, told SCMagazineUS.com. “That's not the case.”
A mature and properly deployed tokenization solution can, however, simplify the requirements of PCI DSS by taking systems that no longer contain sensitive credit card numbers out of the scope of the standard, according to the 23-page supplement released by the PCI Council.
Tokenization technology replaces primary account numbers (PANs), or the 16-digit numbers found on the front of debit and credit cards, with a token value.
Such solutions aim to bolster security by reducing an attacker's ability to steal credit card information stored in databases. Essentially, if a hacker breaks into a system containing tokens, the information should be worthless.
There are at least a dozen different types of tokenization solutions on the market today, and merchants have little guidance, aside from vendor messaging, about how to pick the right one, Russo said. The supplement will help merchants evaluate how a particular product aligns with the standard.
“For a token to be considered out of scope, it has to be unusable if it, or any system it resides on, is compromised,” Russo said. “That's the bottom line.”
Merchants are ultimately responsible for validating the effectiveness of any tokenization implementation, the document, which does not impose any new requirements, states.
Before implementation, organizations should ensure the technology does not provide PAN values in response to any application, system, network or user outside of the merchant's cardholder data systems, the document states. In addition, all components of a tokenization solution must be located on secure internal networks and isolated from any untrusted network.
As an obvious best practice, PANs should not be stored in the same place as tokens, Russo said.
In addition, to meet PCI DSS requirements, a solution should enforce cryptography, access controls, logging, monitoring and alerting, as well as allow for the secure deletion of cardholder data.
“If it's layering security on, that's good,” Russo said. “If it's lulling you into a false sense of security, that's not good. You need to do the homework.”
Many qualified security assessors (QSAs) who validate merchants' compliance with the standard already accept tokenization as a compensating control to address PCI DSS requirements, Adrian Lane, security analyst and CTO at advisory Securosis, told SCMagazineUS.com on Friday.
Tokenization is a “superior strategy” for securing credit card information and reducing PCI obligations, he added.
Large merchants, for example, often house credit card numbers on multiple systems, he said. By using tokenization, organizations can replace sensitive credit card numbers with a token that can't be used for fraud, and the system the token resides on must undergo only “minor” security screening.
“While it's not a surprise that PCI is embracing [tokenization], we are still a little surprised at how long it took them to do so,” he said.
Lane said he wished the PCI Council, in the new guidance, had more clearly specified that the use of so-called format-preserving encryption and hashed-based tokens are not a suitable alternative to tokenization.
Such solutions, which are offered by a number of vendors, do not remove a credit card number, they only encrypt it, he said. Other tokenization solutions replace a credit card number with a random value, so there is no way it can be cracked.
Meanwhile, Sue Zloth, product group manager at payment data security provider Merchant Link, a member of the PCI Council's tokenization task force, told SCMagazineUS.com on Friday that she believes the document is a good first step, though it may lead to some confusion and deter adoption.
Zloth took issue with a section that discusses the need to evaluate whether a token itself could be used – in lieu of cardholder data – to perform a transaction.
The document states that so-called “high-value tokens,” which can be used as a form of payment, could be monetized by an attacker or used to generate fraudulent transactions.
The council introduced a valid concern – that certain tokens could be valuable to attackers -- but "fell down" by failing to describe how a tokenization system could adequately protect tokens from being fraudulently used, Zloth said.
“A properly implemented system will know who is sending transactions and will not allow just anyone to send transactions with a token,” she added.
Visa, in June, issued a four-page document offering best practices for deploying the technology.