12
Sep
10

What Happens Once Merchants Get Rid Of Cardholder Data?

I started thinking about this a couple of months ago.  I think this is one of the problems we have in our industry as well as society as a whole.  We do not take the time to think about what our actions might result in.  If we did, we might not continue to end up with ever larger problems.

There appears to be this belief that once merchants get rid of cardholder data, life will be so much better and safer.  But is that really what will happen?  What does happen once merchants get rid of cardholder data?  Do the clouds part?  Is there sunshine forever?

Granted this is all my suppositions, but I think it probably fairly portrays what will happen once cardholder data is out of merchants’ systems.

Merchants have been led to believe that attackers will have to move their target to where the data will have moved which would be service providers, processors and acquiring banks.  But merchants are not out of the woods once they no longer store cardholder data.  In their efforts to get to the service providers, processors and acquiring banks, the attackers will take whatever route they have to in order to achieve their objective.  Merchants may no longer store cardholder data, but they will transmit it and possibly still process it.

Merchants have to connect to service providers, processors and/or acquiring banks, so they are still part of the transmission of cardholder data.  As security professionals like to say, “Security is only as good as its weakest link.”  Where is the weakest link?  Unfortunately, it will be merchants.  Even though they no longer store cardholder data, they are still a target and will need to continue investing in security so that they protect their business partners.  If you think it was tough selling merchants on securing cardholder data, imagine selling them on securing their business partners after they stop storing cardholder data.

Since merchants will still come in contact with credit cards in order to obtain payment, they will need something like end-to-end encryption or other security measures so that when a customer pays with their credit card, the connection between the card and the processor is secured.  That now makes the credit card terminal or the integrated POS workstation the prime target to intercept cardholder data.  Therefore, criminals will move their focus to supplying merchants or their equipment suppliers with doctored terminals or integrated POS software to intercept cardholder data.  There have already been documented incidents of this happening, so one has to assume that these sorts of incidents will just increase in occurrence.

Chip and PIN can resolve some of this, but as some security researchers recently showed, Chip and PIN can also bring a new set of problems.  Everyone looked at this exploit as too difficult to pull off.  However, if you truly read the researchers’ report, you see that it would only take the doctoring of a terminal to execute.  But the PCI SSC says that terminals are “dumb.”  Yet a lot of the terminals being used these days have the processing capability of a netbook.

To exacerbate the situation with the terminal, you have the problem of what to do when the terminal cannot connect to the service provider, processor or acquiring bank.  Even in this age of high network availability, there will always be the occasional incidence of the knocked over utility pole or network failure.  In these instances there has to be a way to conduct the transaction as merchants are not going to deny sales because the network is down.  There are a couple of ways to deal with this situation.  The first is to fall back to the good old “knuckle-buster” and paper forms.  You then need to deal with the security of the forms, but that can usually be handled the same as how a merchant secures their cash.

The second option is to put a form of intelligence in the terminal or integrated POS solution to conduct the transaction without the network.  However, this involves the temporary storage of the cardholder data in the device until the network is available.  Where this typically goes wrong is that the device does not properly clear the data once it has been transmitted.  Most people would say, “So what?  The attackers would have to know when the network was down.”  True.  But what if the attackers doctored the terminal or POS software and periodically just didn’t allow a certain number of transactions process?  Do you think people would notice?  They would probably write it off as the technology just acting up.

In the end, merchants are only a little better off than when they stored cardholder data.  Until a new system is developed, we need to mitigate the risks of the existing system.  That is what the PCI standards are all about.  They were developed to mitigate the risks presented by the current credit card processing system.  They are not perfect, but they do reduce the risks to an acceptable level if they are followed.

Advertisements

3 Responses to “What Happens Once Merchants Get Rid Of Cardholder Data?”


  1. 1 Nshah
    September 14, 2010 at 8:39 AM

    We faced the same situation. Our strategy has been 100% outsourcing using a hosted page. We ensure that we are not dealing with any credit card numbers in back office for charge back. Also, we have created a tollgate where a new service accepting credit card for payments must be reviewed by the IT Risk Mgmt, security and Treasury. Everything must be 100% outsourced.
    I have heard lot of people say 100% outsourcing is not possible. I have encountered that 100% outsourcing is possible however difficult to get business buy-in. Especially, IVR and eFax processes.

  2. September 12, 2010 at 12:15 PM

    Visa’s recent guidance on Hosted Payment Pages was interesting – http://www.visaeurope.com/en/businesses__retailers/payment_security/downloads__resources.aspx
    So, even if a merchant thinks they are fully outsourced in using a hosted payment page (which would typically fall under SAQ-A), then criminals still appear to be directly targeting the merchant.
    As SAQ-A only covers off Section 9 and 12 for PCI DSS (physical security and policy), then on aggregate, there’s a HUGE exposure to merchants that think they’ve got rid of the problem, as the critical security controls to maintain integrity and check for malware are missing.
    Will the problem go away? Well, the problem as we know it will go away, but another one is going to come along in place, namely that SAQ-A / eCommerce outsourcing leaves far too much of a comfort factor with merchants and lets them all get back to their old habits…

    • September 13, 2010 at 7:33 PM

      Sorry for the confusion. I was thinking about traditional merchants with POS or their own e-Commerce, not those that have truly outsourced everything. However, even those merchants that are supposedly outsourced may still have back office processes for chargebacks and disputes that still bring them into contact with cardholder data. So even those outsourced merchants may not be totally out of woods.


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

September 2010
M T W T F S S
« Aug   Oct »
 12345
6789101112
13141516171819
20212223242526
27282930  

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

Join 1,843 other followers


%d bloggers like this: