Over the last few months, the PCI Knowledge Base has been doing research on the impact of PCI compliance on fraud and fraud management for the Merchant Risk Council. One of the things we've learned is that, in general, the PCI-mandated controls are most effective at reducing internal fraud due to insider threat.
Many of the controls focus on limiting the number of employees who are authorized to access credit card data, whereas others focus on separating the systems that most employees access from the cardholder data environment. But the hottest trends in payment security concern two technologies that go beyond PCI as the standards are currently written. These are tokenization and end-to-end (E2E) encryption.
E2E Encryption addresses a major insider threat today. For many companies, encryption is not centrally managed. It is a feature that is easily added to applications; it's built into operating systems, databases, POS devices and so on. Even within the cardholder environment, it's not uncommon to find a half dozen different implementations of encryption and multiple key management systems.
In this situation, card data may have to pass through multiple systems internally on the way to the acquiring bank or processor. The result is the dreaded "encrypt, decrypt, re-encrypt" scenario, which opens up holes to unauthorized insiders.
With E2E encryption a company encrypts the data at the entry point (the point of sale [POS], the e-commerce payment software and the call center software) and the data remains encrypted throughout the process of passing it to the acquirer. The card number is never stored unencrypted by the merchant.
Several products are available for the POS channel and numerous products are available for the e-commerce channel, but any of these products can be rendered ineffective if a company insists on storing and using the data for other applications.
The other key point of E2E is that some companies are focused on an enterprise view of end-to-end, rather than defining one of the endpoints as the acquirer. In addition, the policies for and the processing of chargebacks in some companies tends to mess up the end-to-end scenario.
The main thing to remember regarding encryption is that it is but one of 12 major PCI-mandated controls, even when it is E2E. It seems unlikely that changes to PCI DSS requirements in the next release in the Fall of 2010 will eliminate the need for the other 11 primary PCI DSS controls, just because one control is in place. But we'll see.
Speaking of things that are no longer needed, there is a lot of discussion about tokenization solving all problems. Tokenization involves the replacement of credit card numbers (or other confidential data) by a surrogate number or "token" and then centralizing (or outsourcing) the card data to reduce (some say eliminate) insider threat.
In an ideal world, that may well be possible. However, in our research, we haven't found any large companies that have been able to completely eliminate or outsource card data even though they implemented tokenization. Some of the reasons include business requirements, the cost to change their production applications and the difficulty of actually finding and purging all their card data.
On the other hand, some smaller organizations, which are single-channel and have a highly centralized data architecture, have been the most successful at handing off the data and compliance headaches to tokenization companies. Therefore, these companies still need to encrypt whatever credit card data remains, in order to be compliant and to minimize insider threat.
Bottom line: Our research suggests that end-to-end encryption and tokenization will likely exist side-by-side in nearly all large and most midsize businesses for the next two to three years. Suggesting that one can take the place of the other does not take into account the reality of the large, multi-channel merchant or service provider.
If you would care comment or share your experiences, e-mail us at David.Taylor@KnowPCI.com.
This story, "Tokenization vs. end-to-end encryption" was originally published by NetworkWorld.