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.
PCI Guru 
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
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.
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…
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!
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.
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.
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.
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.
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.
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.