26
Jul
10

Advice To Merchants

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.

Advertisements

5 Responses to “Advice To Merchants”


  1. August 26, 2010 at 1:55 AM

    A+ would read again

  2. 2 David Griffiths
    August 1, 2010 at 2:01 PM

    Barring the fact that the PCI Guru doesn’t understand real card payment systems and security (I refer my learned friends to the PCI Guru’s appraisal of EMV, which is one of the most inaccurate pieces of anti-EMV twaddle I have yet seen), he makes the point that the PCI standards will be with us along time. We can’t have EMV because it might have weaknesses, but we can have PCI, which we KNOW has weaknesses – no matter how much you might secure, hide or encrypt card data, the card data is STILL there on the card! And it’s now being compromised at petrol pumps across the US, and no amount of PCI jiggery pokery is going to stop it …

    This advice to merchants is based on the premise that card data is intrinsically valuable and must be protected at all costs (better sort out your petrol pumps then). If you tell people that card data is intrinsically valuable enough times, sooner or later they are going to start to believe it, and believe it they do. I the argument is that you are protecting data because the data is valuable, then surely if the data is useless, then it wouldn’t need to be protected. This is the point where the PCI affectionados tell us that they are not EMV experts, but EMV must be bad anyway, because it was in the National Enquirer once.

    If you can convince your merchants that the “valuable” data they are collecting from their customers’ cards is their responsibility, and you can help them look after it, you’re heading off towards consultancy heaven and a permanent meal ticket, at least until EMV comes along that is.

    The problem is that people believe all this stuff, because it’s coming from the mouths of self-proclaimed experts. The problem is that people only see what they want to see. The problem is that once you get a load of self-proclaimed experts all agreeing with each other – “EMV must be bad, even though I don’t understand it, because loads of other experts who understand it equally well, also think it’s bad, so it must be!” – it’s pretty easy to convince the non-experts.

    My advice to all of you merchants is to lobby for EMV, then it’s not your responsibility. Until you do that, you’ll be ever inundated with PCI consultants looking to help. It’s help you don’t need.

    • 3 T. Anne
      August 2, 2010 at 9:58 AM

      The payment card brands view their detail as valuable – they do not want to ruin their reputations because careless merchants or vendors do not protect the detail. If EMV was the perfect security solution and would get rid of the need for the PCI DSS, then the card brands wouldn’t require those with that technology in place to still adhere to it. Yet they do, example from list of what cannot be stored directly from Visa “Full contents of any data taken from the Magnetic Stripe (on a Card, in a Chip, or elsewhere)”. I would think the payment card brands can be considered experts who know what’s going on – if they still require PCI DSS in areas using Chip and PIN, then clearly there’s a reason for it.

      I do not believe the argument against EMV is that it’s useless – the point is, that it does not get rid of the need for PCI compliance. It may have its benefits – but there are still security risks that need to be addressed… those are addressed (at the min level of security) through the PCI DSS requirements which is why it’s a requirement.

      Regarding advice to the merchants… I agree that there are things that simplify their PCI compliance and the way merchants do that may differ based on their business needs. However I disagree with the comment to stop trying to comply and just get rid of the data in the first place. Yes, that may be the way to limit most of the PCI DSS complications as there’s no data to secure, but isn’t the whole point of the PCI DSS to give businesses a way to function as they need to and be compliant in order to reduce risk? If it were a one-size fits all type of fix, why wouldn’t they have just required everyone to stop storing it in the first place? Or do you think that’s where the PCI DSS is headed and that they’re simply gradually making changes so everyone isn’t hit hard at the very beginning?

      I can see that approach working for some, but not everyone – which is why I don’t think the PCI DSS made that a requirement. I don’t think companies that still have cardholder data are simply trying to comply at the lowest level (now yes there are some of those I’m sure – but not all). If anything, continuing to house that detail puts more responsibility in their court and complicates compliance because of all the additional requirements – it’s not the easy way out. And while at the beginning it may be because they’re used to having it – but over time I would think those that choose to still go through the hassle year after year are those that truly need it for one reason or another.

  3. July 29, 2010 at 2:24 PM

    I love the mention of the travel industry. I work in a part of that industry and going through PCI is pretty much a digital corporate landscape makeover extreme when it comes to segregating everything and reducing scope. And yes, we’re very far down the token road, but it’s still painful when a large chunk (~75%) of the organization has some contact with such data.

    I need to read where you linked, but I wonder how many of those POS-related incidents wouldn’t have been solved with non-storage devices; things like skimmers, transmission interceptions, or outright device replacements.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

July 2010
M T W T F S S
« Jun   Aug »
 1234
567891011
12131415161718
19202122232425
262728293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,798 other followers


%d bloggers like this: