Tokenisation Guidelines from PCI SSC - Review
The full document can be found on the PCI DSS website and also on my own site.
Overall the document provides a good overview of tokenisation and is a recommended read for any organisations looking at deploying tokenisation to increase security and reduce PCI DSS Scope.
However, it does fall short in stating the benefits of tokenisation, the language in the document is, in places, very noncommittal.
For example, take the following quotes in the introduction (1.3):
…potentially reducing the merchant’s effort to implement PCI DSS requirements.
…but they may simplify a merchant’s validation efforts by reducing the number of system components for which PCI DSS requirements apply.
Not exactly the clear cut statement I was hoping for.
Does tokenisation reduce scope? Maybe! Great, how does this change the situation organisations where in before the document was published?
The bulk of the document contains information about various tokenisation components and methods, for example how tokens should and should not be generated, what a token actually is, key management and network segmentation; all in all, worth a read.
Once we get towards the back of the document, more noncommittal statements start springing up:
…System components that are adequately segmented (isolated) from the tokenization system and the CDE; and that store, process or transmit only tokens; and that do not store, process, or transmit any cardholder data or sensitive authentication data, may be considered outside of the CDE and possibly out of scope for PCI DSS (Section 3.1).
So to conclude. The document is a must read for any organisations that are looking at, or currently implementing a tokenisation solution, but be aware that the council are not coming out and stating that this will reduce scope; organisation will, as ever, need to work with a good QSA to assess the impact of tokenisation.
PCI DSS Compliance - Storing Credit Card Data
First off, what is PCI DSS? If you’ve worked in Ecommerce at all, there’s a good chance you’ve heard the term “PCI DSS compliant” tossed around. PCI DSS stands for the Payment Card Industry Data Security Standard. This standard was developed to improve protection for credit card holders by enforcing vendors to adhere to a specific set of guidelines for storing, processing, and transmitting cardholder data. With the massive growth and convenience in Ecommerce, it’s difficult not to buy online. Online shopping, like anything else on the web, is never completely safe, but with the knowledge that the cart you are punching your credit card number into is PCI DSS compliant, you’ll have more of that warm fuzzy feeling inside.
Second, a little history. PCI DSS was created on December 15, 2004 by the Payment Card Industry Security Standards Council (PCI SSC), another awesomely long acronym, consisting of 5 major players in the credit card biz - Visa, Mastercard, American Express, Discover, and the JCB (Japan Credit Bureau). Each company originally had their own programs established, but came to realize all had similar motives. They came together to develop a universal set of standards, and PCI DSS was born.
As a web developer working on implementing a new shopping cart, there have been many questions about the dos and don’ts on storing credit card info. Storing any kind of credit card information can potentially be a security risk, but at the same time can also significantly improve the user experience in a cart leading to more sales, return traffic, etc.. The following chart comes from the Payment Application Data Security Standard (PA-DSS), which is derived from the PCI DSS. The chart depicts which and how credit card data can be stored.
Basically, no sensitive authentication data can ever be stored. Cardholder data may be stored with one exception. The Primary Account Number (PAN) must be unreadable according to DSS Requirement 3.4. After referring to Requirement 3.4, the PAN may only be stored using “Strong Cryptography”.
Both images were pulled straight from the PCI SSC specs.
Fulfilling all of the requirements of the PA-DSS does not make your cart PCI DSS compliant. You will also need the cart installed in a PCI DSS friendly environment (a story for another time), but it’s a necessary step in the process.
Pravin Kothari, Founder and CEO of CipherCloud, comments on the recent Global Payments breach
“While MasterCard and Visa continue to investigate the massive security breach of Global Payments, what’s most shocking is that breaches happen so often that it’s actually not shocking anymore. This time, over 50,000 Visa and MasterCard cardholders may have had their personal data stolen. Although the breach details are not yet disclosed, people familiar with the investigation estimated that it could be hundreds of thousands.
“The breach is an example of why PCI DSS compliance is inadequate. In spite of growing profits and huge revenues in billions of dollars, companies such as Global Payments are focusing more on doing minimal to somehow obtaining compliance certification than on really protecting their customer data. If companies don’t implement enough controls to protect sensitive data, it’s only a question of when, not if, a breach will happen as cybercriminals are becoming highly advanced and organized. A small missing technical control can become executives’ nightmare and business disaster on such breaches as they suffer significant impact on reputation, revenues and stock prices.
“It’s time for organizations to take greater responsibility for the protection of their customers’ sensitive data, regardless of where it resides—behind their firewall, with a business partner, or in the cloud. Demanding that businesses encrypt sensitive customer data is a step in the right direction.”
Tokenisation Guidelines from PCI SSC
Not fully had a chance to digest this yet and I’ll cover it in more detail in a future post. But for now here is the link to the document on my website (also available at the PCI website as well).
PCI 2.0 Prioritised Approach
The PCI Council has recently released the updated version of the prioritised approach to PCI. Fortunately not much has changed, but for those looking at milestones 1 and 2 via VISA TIP, attention much be given to the requirements that have moved into these milestones and one will need to assess the impact to the project.
All the documents are available on the PCI Council website:
For convience I have added them to my website:
In summary, the following requirements have moved milestones:
- PCI DSS Requirement 9.1 moved to Milestone 2
- PCI DSS Requirement 10.5 moved to Milestone 4
- PCI DSS Requirement 11.1 moved to Milestone 4
- PCI DSS Requirement 11.3 moved to Milestone 2
- PCI DSS Requirement 12.1.2 moved to Milestone 1
- PCI DSS Requirement 12.5.3 moved to Milestone 4
- PCI DSS Requirement 12.9 moved to Milestone 4