20
Jul
14

Keeping It Simple – Part 1

Apparently, I struck a nerve with small business people trying to comply with PCI.  In an ideal world, most merchants would be filling out SAQ A, but we do not live in an ideal world.  As a result, I have collected some ideas on how merchants can make their lives easier.

Do Not Store Cardholder Data

It sounds simple, but it amazes me how many small businesses are storing cardholder data (CHD).  In most cases, it is not like they wanted to store CHD, but the people in charge just did not ask vendors that one key question, “Does your solution store cardholder data?”  If a vendor answers “Yes”, then you should continue your search for a solution that does not store CHD.

Even when the question is asked of vendors, you may not get a clear answer.  That is not necessarily because the vendor is trying to hide something, but more likely because the salespeople have never been asked this question before.  As a result, do not be surprised if the initial answer is, “I’ll have to get back to you on that.”  If you never get an answer or the answer is not clear, then you should move on to a different vendor that does provide answers to such questions.

If your organization cannot find a solution that does not store CHD, then at least you are going into a solution with your eyes open.  However, in today’s payment processing application environment, most vendors are doing all that they can to avoid storing CHD.  If the vendors you are looking at for solutions are still storing CHD, then you may need to get creative to avoid storing CHD.

That said, even merchants that only use points of interaction (POI) such as card terminals can also end up with CHD being stored.  I have encountered a number of POIs that were delivered from the processor configured such that the POI was storing full PAN.  Apparently, some processors feel it is the responsibility of the merchant to configure the POI securely even though no such instructions were provided indicating that fact.  As a result, you should contact your processor and have them walk you through the configuration of the POI to ensure that it is not storing the PAN or any other sensitive information.

Then there are the smartphone and tablet solutions from Square, Intuit and a whole host of other mobile solution providers.  While the PCI SSC has indicated that such solutions will never be considered PCI compliant, mobile POIs continue to proliferate with small businesses.  The problem with most of these solutions is when a card will not work through the swipe/dip and the CHD is manually keyed into the device.  It is at that point when the smartphone/tablet keyboard logger software captures the CHD and it will remain in the device until it is overwritten which can be three to six months down the road.  In the case of EMV, the device can capture the PIN if it is entered through the screen thanks to the built in keyboard logger.  As a result, most EMV solutions use a signature and not a PIN.  The reason Square, Intuit and the like get away with peddling these non-compliant POI solutions is that they also serve as the merchant’s acquiring bank and are accepting the risk of the merchant using a non-compliant POI.

The bottom line here is that merchants need to understand these risks and then make appropriate decisions on what risks they are will to accept in regards to the explicit or implicit storage of CHD.

Mobile Payment Processing

The key thing to know about these solutions is that the PCI Security Standards Council has publicly stated that these solutions will never be considered PCI compliant.  Yes, you heard that right; they will never be PCI compliant.  That is mostly because of the PCI PTS standard regarding the security of the point of interaction (POI) for PIN entry and the fact that smartphones and tablets have built in keyboard loggers that record everything entered into these devices.  There are secure solutions such as the Verifone PAYware line of products.  However, these products only use the mobile device as a display.  No cardholder data is allowed to be entered into the mobile device.

So why are these solutions even available if they are not PCI compliant?  It is because a number of the card brands have invested in the companies producing these solutions.  As a result, the card brands have a vested interest in allowing them to exist.  And since the companies offering the solutions are also acting as the acquiring bank for the merchant, they explicitly accept the risk that these solutions present.  That is the beauty of the PCI standards, if a merchant’s acquiring bank approves of something, then the merchant is allowed to do it.  However, very few merchants using these solutions understand the risk these solutions present to them.

First is the risk presented by the swipe/dip device.  Some of these devices encrypt the data at the swipe/dip but not all.  As a result, you should ask the organization if their swipe/dip device encrypts the information.  If it does encrypt, then even if the smartphone/tablet comes in contact with the information, it cannot read it.  If it is not encrypted, I would move on to the next mobile payments solution provider.

The second risk presented is the smartphone/tablet keyboard logger.  This feature is what allows your mobile device to guess what you want to type, what songs you like and a whole host of convenience features.  However, these keyboard loggers also remember anything typed into them such as primary account numbers (PAN), driver’s license numbers and any other sensitive information they can come into contact.  They can remember this information as long as it is not overwritten in the device’s memory.  Depending on how much memory a device has, this can be anywhere from weeks to months.  One study a few years back found that information could be found on mobile devices for as long as six months and an average of three months.

While encrypting the data at the swipe/dip will remove the risk that the keyboard logger has CHD, if you manually key the PAN into the device, then the keyboard logger will record it.  As a result, if you are having a high failure rate with swiping/dipping cards, you will have a lot of PANs contained in your device.

The bottom line is that if you ever lose your mobile device or your trade it in, you risk exposing CHD if you do not properly wipe the device.  It is not that these solutions should not be used, but the purveyors of these solutions should be more forthcoming in the risks of using such solutions so that merchants can make informed decisions beyond the cheap interchange fees.

There are more things merchants can do to keep it simple and I will discuss those topics in a future post.

About these ads

10 Responses to “Keeping It Simple – Part 1”


  1. 1 Louis
    July 23, 2014 at 11:18 AM

    Handheld POI’s are able to behave in a semi-integrated mode using the iPhone or Android as a network service, using bluetooth or directly to the Internet using WiFi. The POI is configured as an electronic cash register (ecr) and it connects directly to the processor/acquirer network.

    In such cases, SSL is used to encrypt data between the POI and the gateway, the mobile device is blind to CHD.

    The only actual communication between the POI and the mobile device is through a “driver” app on the mobile and all it does is signal a trx, with amount and invoice number and obtain an auth result&code in return.

    Diligent payment processors provide this information to ISO’s and merchants.

    I find awareness programs aimed at merchants are lacking in depth, which is disturbing

    • July 24, 2014 at 5:04 AM

      While I agree with your statements for “secured” point of interface (POI) running on iOS, Android and Windows (mobile versions), that is not the case for all such mobile POI.

      However, the minute you manually enter cardholder data (CHD) into an iOS, Android or Windows POI, the data is recorded in that device and will remain there until over written. Some vendors such as Verifone do not provide the capability for the manual entry of CHD into an iOS, Android or Windows POI.

  2. July 22, 2014 at 10:43 AM

    The cell phone or tablet cannot be connected to a network, but must be “connected via IP to merchant’s payment processor”. Do you really think all other functionality of these mobile devices – like their ability to be used as a phone – are disabled? Maybe they are, I’ve never evaluated one as a QSA. Another requirement is that the stand-alone IP-connected POI devices are validated to the PTS POI program…is that happening?

    Methinks the purveyors of mobile payment devices are lying…

    • July 23, 2014 at 5:37 AM

      Jeffrey Man, it doesn’t matter. The acquirer has deemed the device allowed for the processing of transactions regardless of other PCI standard/requirements. Move on, there is nothing to see here. LOL!

  3. July 22, 2014 at 5:53 AM

    Thanks for the answer. I guess the merchant has to be careful to make sure that the solution they’re using doesn’t store CHD otherwise SAQ B-IP won’t apply.

    • July 22, 2014 at 8:37 AM

      In some cases, you may not know if the solution is storing CHD or not unless the vendor of the solution shares that information. As Jeffrey Man points out, the acquirer is accepting the risk that the mobile device may contain some CHD as “incidental contact” as 99%+ of cards should swipe/dip with no issue.

  4. July 21, 2014 at 12:49 AM

    Excellent and information article :) Two quick Questions, if a merchant is using a non-compliant PCI solution such as the one’s above, what SAQ should they be using? They can’t use B as they are storing CHD.

    If the solution isn’t PCI compliant, how can a acquiring bank ‘sign off’ a merchant as being PCI compliance?

    Keiron.

    • July 21, 2014 at 4:08 AM

      I’m assuming you are referring to the mobile payment solutions. They are allowed because the acquiring bank, in this case the mobile payment solution provider, is willing to accept the risk of their merchants using their mobile payment solution. Under v3 of the PCI DSS, these merchants will fill out an SAQ B-IP is what we are assuming.

      • July 21, 2014 at 8:03 AM

        The new v3 SAQs are pretty rigid in terms of their qualifiers, and in this case I think the merchants should be completing SAQ-D (Merchant) version. The very first qualifier for SAQ B-IP is that the solution is stand-alone (e.g. not interconnected with a local or wide area network).

        As a general rule, SAQ D is the appropriate option unless the very stringent qualifiers for all forms of SAQs A – C are satisfied.

        And it is not that the acquiring bank is signing-off that the merchant is compliant; they are accepting the risk of the merchant being non-compliant.

      • July 22, 2014 at 5:34 AM

        But a cell phone or tablet would be the only device connected to a network, so that is why SAQ B-IP works. Besides, that is what the purveyors of mobile payment devices are telling their customers to do for PCI DSS v3.


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

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

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 2014
M T W T F S S
« Jun   Aug »
 123456
78910111213
14151617181920
21222324252627
28293031  

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

Join 941 other followers


Follow

Get every new post delivered to your Inbox.

Join 941 other followers

%d bloggers like this: