Why does the card securities council not care about card security?

I mentioned that I spent last Friday morning with card fraud and security experts. The conversation began with a wide view of what’s happening, and a focus upon PCI DSS Standard 2.0, which is yet to be published.

The Payment Card Industry (PCI) Securities Standards Council (SSC) have developed new versions of the PCI Data Security Standard (PCI DSS) and Payment Application-Data Security Standard (PA-DSS) for release at the end of October, which will then last three years in implementation.

After that period, there will be a one-year sunset before the next generation of PCI standards take over.

This is based upon the new agreement in the cards markets which means that every three years a new standard is released to keep up with market and technology change, with a year to implement the new standards and phase out the old one.

Source: PCI Lifecycle Factsheet

The fact that the new standard appears to be an evolution of the old standard, with no changes to merchant technology, is a good thing some say, as it means no major budget changes to card machines.

However, it’s not a good thing as it ignores many key areas of technological development within the card community, such as server and desktop virtualization, tokenization of regulated data, end-to-end encryption (E2EE) of card holder information and the use of cloud-based applications.

This is interesting as card processors, such as Visa, are offering guidelines in these areas, such as Visa’s best practices for tokenization.

Tokenization is a relatively recent practice whereby credit card data is changed to ensure data thieves cannot steal it, for example by only communicating the last four digits of the credit card. The view being that if the data’s not there, it cannot be stolen.

Their report makes an interesting read:

“In October 2009, Visa published the Visa Best Practices for Data Field Encryption to promote the proper encryption of sensitive card data that is transmitted, processed or stored by stakeholders throughout the payment system. As part of these best practices, Visa recommended that entities use tokens (such as a transaction ID or a surrogate value) to replace the Primary Account Number (PAN) for use in payment-related and ancillary business functions.

“Tokenization can be implemented in isolation or in concert with data field encryption to help merchants eliminate the need to store sensitive cardholder data after authorization. Entities that properly implement and execute a tokenization process to support their payment functions may be able to reduce the scope, risks and costs associated with ongoing compliance with the Payment Card Industry Data Security Standards (PCI DSS).

“How Tokenization Works

“Tokenization defines a process through which PAN data is replaced with a surrogate value known as a ‘token’. The security of an individual token relies on properties of uniqueness and the infeasibility to determine the original PAN knowing only the surrogate value. As a reference or surrogate value for the original PAN, a token can be used freely by systems and applications within a merchant environment.

“Where properly implemented, tokenization allows merchants to limit the storage of cardholder data to within the tokenization system, potentially simplifying an entity’s assessment against the PCI DSS. As a reference or surrogate value for the original PAN, a token can be used by systems and applications within a merchant environment without having to consider the security implications associated with the use of cardholder data.

“The security and robustness of a tokenization system is dependent upon the secure implementation of four critical components, and the overall management of the system and any historical data:

• Token Generation: Defines the process through which a token is generated.
  
• Token Mapping: Defines the process for associating a token to its original PAN value.
• Card Data Vault: Defines the central repository of cardholder data used by the token mapping process.
• Cryptographic Key Management: Defines the process through which cryptographic keys are managed and how they are used to protect cardholder and account data.”

I’ve placed most of this explanation here, to ensure the dialogue is clear in these areas, with the other big discussion area being E2EE.

End-to-end encryption (E2EE) ensures sensitive credit and debit card data is protected from the card being used at a PIN Entry Device (PED) or other card reader, throughout its transmission via the network to the payment processor.

This is achieved by using the latest card readers, which scan and encrypt the cardholder information prior to performing an electronic payment transaction.

These sophisticated devices use Triple Data Encryption Algorithm (DES) Encryption with a Derived Unique Key per Transaction (DUKPT) to encrypt and transmit cardholder data securely over any network.

The terminals also use tokenization to ensure that the encrypted cardholder data transmitted is not the same as the original cardholder data in any way. This means that even if the encrypted data were to be intercepted and somehow compromised, it would be useless to data thieves.

So why is that the PCI SSC is producing a new standard that appears to ignore areas the key areas of tokenization and E2EE, when these clearly help to get to the dream of fraud proofing card payments?

According to the conversation with the guys last week: cost and bias.

The cost issue is an easy one: it would cost a lot of money to upgrade all terminals to be compliant with a mandate for tokenization and E2EE. Think of the UK’s investment in Chip & PIN and make that global, and you get the picture. After all, these standards are mandates, and this is why the SSC is clarifying and making recommendations rather than mandating for these changes to be incorporated.

The bias one is more interesting for me however.

The bias exists in two forms: first, geographic and second, who sets the standards.

The geographic bias exists in the form of many of the key decisions being made to cater for US markets which lay way behind the worlds’ markets. The fact that most card fraud is now emanating from US markets is because they are so far behind.

In fact, it does amaze me that the world’s most advanced economy and undisputed internet and technology leadership should be stuck in the 20th century model of cheque payments and mag stripe card readers. What is all that about?

Cost and laziness.

I mean, come on America, get with the 21st century and start thinking about Chip & PIN and EMV.

Or maybe not.

As PCI Guru sees it: “EMV will save US banks and merchants a total of around $394 million dollars annually. Given the estimated ten billion it will cost to convert totally to EMV, is it any wonder why banks and merchants have no incentive to convert?”

OK, but the SSC still has some questions of bias based upon who sits on the Council, which includes firms such as Cisco, First Data, PayPal and Verifone, alongside banks, merchants and the EPC.

The accusation made by those over here, who have to follow their directions, is that some of these organisations are more there to promote and protect their own systems and solutions, rather than the promotion of best practice in the industry.

Not sure I agree with that accusation, but it was an interesting one.

Maybe this means there should be more interface, dialogue, discussion and cooperation between gropus such as the PCI SSC and the MRC (Merchants Risk Council).

In fact, the most surprising outcome of my dialogue with securities assessors, card encryption firms, and PCI DSS experts last week, is that they had not heard of, or were even aware of, the MRC.

Whoops.

“The Merchant Risk Council (MRC) is a merchant-led trade association focused on electronic commerce risk and payments globally. The MRC was formed when two entities decided to join forces: the Merchant Fraud Squad and the Internet Fraud Round Table.

“The Merchant Fraud Squad was founded in September of 2000 by American Express, ClearCommerce and Expedia. The membership quickly grew and, by the end of 2002, the primary focus was to educate online merchants on how to prevent fraud.

“In 2001, HP and ClearCommerce founded the Internet Fraud Round Table, a grassroots group of large retail merchants, to share best practices through twice a year face-to-face meetings and monthly conference calls. By the end of 2002, the Internet Fraud Round Table had grown to over 60 marquee e-Commerce retailers.

“At the end of 2002, the two groups teamed up to form the Merchant Risk Council.”

 

If you like the Finanser, check out the books of the blog: the new Complete Banker Series

Comments

[Steve Brunswick, Thales]

The card schemes and PCI-SSC are naturally cautious. They like to make sure that what they put into their requirements is security standards based, NIST approved etc. PCI DSS 2.0 is a set of requirements built on standards rather than a standard itself. But there are no standards for tokenisation and E2EE, so they can't go in. Meanwhile the industry and the vendors that serve it are driving forward with implementations of end-to-end encryption and tokenisation to "protect cardholder data" (PCI-DSS requirements 3 and 4), and we have an impasse. To break this, (PCI-SSC do know they can't ignore what's actually happening, and recognise it is of value to improve security), we are getting guidelines promised for the same time as PCI-DSS 2.0 - and none too soon given how the industry is racing ahead anyway. The situation will resolve itself in time (in time for PCI-DSS 3.0?) when X9.119 deliver their tokenisation and E2EE standards. PCI-DSS and other PCI-SSC documentation can then refer to this, as they do to other X9 standards today.