Welcome, Gartner Blog Network readers! This is my first post here after joining Gartner on August 1, 2011. As a matter of quick introduction, I am now part of SRMS Burton IT1 team, focusing on PCI DSS compliance, vulnerability management, SIEM/log management, security metrics and other fun areas within broader information security. In fact, PCI DSS has been one of my key focus areas and I even co-wrote a book on the subject – “PCI Compliance” (Syngress, 2010 – book site). If you’d like to know more about me, please check my personal site, my LinkedIn profile and follow me on Twitter.
My first post here is about PCI DSS and tokenization. Look for my upcoming research guidance on PCI DSS compliance later this year.
If you are turning an integer number into another integer number, are you encrypting or tokenizing? Specifically, if a payment card PAN turns into a nondescript 16 (or 15 – for AmEx) digit number, are you producing cipher text from plain text or are you replacing a number with a token? Recently issued "Information Supplement: PCI DSS Tokenization Guidelines" from PCI Council provides some answers to many questions (just not the above mentioned one…) merchants have about tokenization. The document focuses on all technologies that are labeled “tokenization” or replacing sensitive information with “surrogate value” or “token.” In most cases such technology seeks to help reduce the proliferation of PANs across the merchant network.
As with other supplemental guidance documents, this document “does not replace or supersede requirements in the PCI Data Security Standard.” No new compliance requirements are brought forth, but it is likely that the document will affect call merchants are operating or implementing tokenization technologies. It also means that there is now an official acceptance that tokenization is a valid approach for reducing PCI compliance burden and improve in payment security. Thus merchants have a roadmap two secure and compliant and deployments of various tokenization technologies.
While it is too early in the life cycle of this document, but it is likely that it will make merchants more open towards tokenization solutions, but only those that follow the guidance set forth in his document. Some of the interesting highlights follow below.
"PAN is not retrievable from any system component removed from the scope of PCI DSS."
The above will hopefully be remembered by both merchants and QSAs while assessing the tokenization tools running in production environments.
The document does come close to resolving that “question of mystery” by stating that: "Note that where token generation is based on a reversible encryption method (where the token is mathematically derived from the original PAN through the use of an encryption algorithm and cryptographic key), the resultant token is an encrypted PAN, and may be subject to PCI DSS considerations in addition to those included in this document." In other words, reversible, encryption-based tokens are simply … encrypted PANs which are likely subject to PCI DSS controls.
The full answer is “coming soon”: "The PCI SSC is further evaluating how these considerations may impact PCI DSS scope for reversible, encryption-based tokens."
Another useful reminder – the data that cannot ever be stored (even encrypted) cannot be tokenized either: "Tokenization of sensitive authentication data (including magnetic stripe data or equivalent on a chip, CAV2 / CVC2 / CVV2 / CID data, and PINs/PIN blocks) is not permitted per PCI DSS Requirement 3.2."
Users of external tokenization tools should know that if they can see the PANs, PCI DSS scope is still there: “If PAN is retrievable by the merchant, the merchant’s environment will be in scope for PCI DSS." It goes without saying that tokenization systems must be monitored closely, in full compliance with PCI DSS: "The tokenization solution implements logging, monitoring, and alerting as appropriate to identify any suspicious activity and initiate response procedures."
A really curious observation is made in regards to telling PANs and tokens apart: "a specific tool may need to be utilized or function performed to verify that an alleged token is actually a token and not a PAN."
An ultimate test of "Before a system or network can be deemed out of scope for PCI DSS, it must first be verified that the system/network is not connected to the CDE and that it cannot retrieve or access PAN or other account data" or even “influence the security of cardholder data or the CDE."" Only then:
"A properly implemented tokenization solution can reduce or remove the need for a merchant to retain PAN in their environment once the initial transaction has been processed. With adequate segmentation and process controls, a tokenization solution could help minimize the number of merchant system components that need to be protected according to PCI DSS."
While you are reading this, please also read a post from my colleague Ramon Krikken on the same topic.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.