Advice for Merchants on PCI DSS

Tuesday, August 31, 2010

PCI Guru

Fc152e73692bc3c934d248f639d9e963

Barring the card brands developing a truly secure card processing process, the PCI DSS and related standards are likely to be with us for quite a while.  That said, what is the future of complying with the PCI DSS?

For merchants, if you are not seeking out point-of-sale (POS) solutions that do not store cardholder information, you should be as soon as you possibly can. That includes finding card processors that do not require you to store cardholder information and can provide you access to cardholder information when you need it for resolving disputes and chargebacks.

According to Robert McMullen, CEO of TrustWave, the majority of breaches TrustWave investigated occurred with POS systems.  So the rational approach to resolving this problem is to get rid of the cardholder data stored on these systems.

The problem with this is that most merchants, large or small, think that they need to store this information for some reason.  If you are a merchant in the United Kingdom, France, Italy and other select European countries, then you do need to have the PAN unencrypted, however it only is required on an original printed receipt, it is not required to be stored anywhere else. 

So, all merchants need to put POS solutions in place that do not store cardholder data.  You do not need it and it puts you at risk if you do store it.

The next thing merchants need to do is to find a card processor that does not require the merchant to store cardholder data.  This can be a processor that uses tokenization or whatever, but the bottom line is that the processor does not return cardholder data to the merchant’s systems. 

These processors typically provide secure Web-based systems that allow the merchant to view all of their transactions processed and, if necessary, provide a method to decrypt the PAN for dispute research and chargebacks. 

Merchants need to restrict access to the processor’s applications to only those people that absolutely need access to perform their job.  These people should be reviewed at least quarterly to ensure that they continue to require access.

For those of you that just cannot get rid of cardholder data, there is the option of hashing.  Hashing allows applications such as fraud discovery, member tracking, rewards programs and similar functions to continue, they just do not have access to the actual PAN. 

A hashed PAN results in the same hashed value, so research and analysis of PANs can still occur.  It is just that if you need to see the real PAN, you will have to go to the processor’s system to obtain the real PAN.

The travel industry, in particular hoteliers, are really behind the eight ball on PCI because of their need to keep the PAN for sometimes years because of the way reservations work.  However, this is where tokenization can earn its keep. 

If a hotel takes a reservation and gets back a token when the credit card is authenticated, then the hotel can use the token however many times in the future for check in and check out.  Again, there is no reason for the hotel to need to retain the actual PAN.

The bottom line to all of this is that there are ways to minimize your organization’s PCI compliance efforts just by getting rid of the data in the first place.  So, stop putting forth efforts to comply and get with the movement to get rid of the cardholder data in the first place. 

I have had a few clients go down this road and PCI compliance is now a piece of cake.  Their networks are still in scope for transmission, their applications in some cases do process cardholder data, but there is not storage which makes them much, much less of a target.

Cross-posted from PCI Guru

Possibly Related Articles:
3594
PCI DSS
Banking
PCI DSS
Post Rating I Like this!
C643eec6350152c6c3fbd1288578d98a
Terry Perkins Great article. Thanks!
1283356136
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.