The PCI Security Standards Council recently made news when they announced that they would no longer be accepting mobile payment applications for PA-DSS compliance consideration. This means that vendors looking to certify new mobile applications or devices are now left in the lurch.
But we have to dissect this rather knee-jerk reaction (see, there I go again) by the Council to understand exactly their intent. What they said was:
“No mobile payment applications used by merchants to accept or process payment for goods and services would be approved or listed as validated PA-DSS applications unless all requirements can be satisfied as stated… Until it has completed a comprehensive examination of the mobile communications device and mobile payment application landscape, the Council will not approve or list mobile payment applications used by merchants to accept and process payment for goods and services as validated PA-DSS applications unless all PA-DSS requirements can be satisfied as stated and the underlying mobile communications device supports the merchant’s PCI DSS compliance.”
If you are a merchant looking to deploy a mobile payment system, don’t fret! It is still possible to deploy a system that complies with PCI DSS (which is really the key here), and if you can demonstrate its ability to comply with PA-DSS you shouldn’t have any problems with your Acquirer during your normal PCI DSS assessment cycle. Here are some of the highlights that I would focus on to make sure that your mobile application complies with PCI DSS.
Harden the system (PCI Requirement 2.2): Can’t be said enough. Too many compromises today still could be prevented with firewalls, anti-virus, and non-default settings and passwords. And don’t just look at your mobile terminals, look at the entire set of infrastructure that supports it. You should be reviewing wireless access points, routers, switches, firewalls, underlying operating systems for controllers (and terminals), and ensure that your network is designed with defense in mind.
Anti-Virus (PCI Requirement 5, PA-DSS Requirement 8.1): Is the implemented platform commonly affected by viruses? This one is going to be challenging to demonstrate to some QSAs because they may focus on the risks from open mobile systems (such as Android and jailbroken iPhones). Without getting into a detailed discussion about what is happening today and whether it is relevant to PCI DSS, I would suggest that anything deployed should be on a closed and/or managed platform.
Logging (PCI Requirement 10, All over PA-DSS): Be sure that your controllers log all administrative functions (as do the terminals themselves depending on your setup) and are able to pass relevant logs to your centralized correlation engine. Also, be sure that there is zero sensitive authentication data written to logs. I can’t stress this enough. PA-DSS requires that assessors do forensic examinations of the application to ensure that none of this data is written to disk, or if it is on a temporary basis (say in a store & forward scenario) that it is encrypted while used and securely erased when finished.
Encryption (PCI Requirement 3 and 4, PA-DSS Requirement 2): This one falls into two different categories—link level encryption and storage. Your terminals should not be storing anything if they are optimally designed and deployed. But if they do, ensure there is strong encryption protecting any cardholder data stored on the device. Use good link layer encryption as well. Don’t rely on the “implied security”1 of a cellular data connection to keep the data safe. If you are lost on what to do here, the easiest thing to implement to ensure uniform protection (regardless of the link type) is an SSL tunnel to wrap all of your traffic to and from the payment application.
Implementation Guide (PA-DSS requirement, peppered in multiple requirements): Even if the Council won’t validate an application today, you can and should follow the vendor’s PA-DSS implementation guide for the solution, and demonstrate to your Acquirer and QSA that you have done so. The implementation guide is the key to ensuring that you configure your application in a way that supports PCI DSS compliance. This is not foolproof, of course, but it is a good cheat sheet for your IT and other implementation teams.
Authentication (PCI Requirements 2.3 and 8): The mobile device should be treated just like any other POS terminal for PCI DSS compliance in this regard. Administrative functions should be locked down and logged when accessed, and clerks should not have to adhere to the same requirements that an administrator should.
Physical Security (PCI Requirement 9): Physical security with a mobile device is a bit of a challenge, isn’t it? How can I physically secure the device if a waitress could slip it in her purse on the way out? Take the mobile device itself out of it and instead focus on the controllers and infrastructure. The device itself should not have any data on it anyway, and users should not be able to retrieve cardholder data en masse from the device. The physical infrastructure that powers the device, however, could be quite vulnerable to a number of attacks depending on it’s physical location in the store, especially if you have false ceilings.
PINs (PCI Requirement 3.2, PA-DSS Requirement 1): I might be going out on a limb here, but PIN-based debit might be something to avoid with mobile payments. The cost savings are getting narrower, and the hassle of dealing with the PIN over the electronic signature capture causes pain. It’s been a long time since I have seen someone pay with a PIN-based debit card in the US that was not attached to a major payment brand. You can run those as credit instead.
Wi-Fi vs GSM (PCI Requirement 4.1, 9.3, PA-DSS Requirement 6): As I mentioned above, you shouldn’t trust a network to be secure just because it is difficult to snoop. And in the case of GSM, it’s not that difficult anymore. What used to take tens (if not hundreds) of thousands of dollars of equipment now can be done for less than one thousand, including the laptop. If you choose to use GSM, do yourself a favor and encrypt that traffic. Frankly, GSM, CDMA, or other types of cellular data services might work better for you over a Wi-Fi solution depending on your available coverage, availability, and hardware types. If you use Wi-Fi, I’d be tempted to just do an SSL tunnel inside your WPA/WPA2 encryption for good measure.
Policy (PCI Requirement 12): What does your current information security policy say about wireless technology? The last thing you want to do is violate your own corporate policy and then have a QSA walk in the door to do an assessment. You might also want to include these devices as part of your usage policy for critical technologies (Requirement 12.3).
Vulnerability Detection/Remediation (PCI Requirements 6.1-6.2, 11.1-11.3): This is a big one, and I want to focus on the PCI DSS side of the equation here. Sure, you might get lucky and find a signature hit on a vulnerability in a TCP/IP stack on a device, but you will get much more bang for your buck by concentrating on identifying new attacks and ways to compromise the device or the infrastructure. I’m not saying you should ignore quarterly scanning. I’m saying you should put more time and effort into the annual penetration test, code reviews where appropriate, and into finding new ways to attack your devices.
One of the most important things to remember is that when you are comparing your systems to PCI DSS or PA-DSS, you are working with a compliance initiative, not a security initiative. When you are using mobile payment terminals, don’t just stop at compliance. The Council even hinted that they don’t fully understand the ramifications which is what started this whole mess in the first place. Push for a secure solution, and over-engineer if you have to. Make someone else the target of a breach.
- Implied because it is really not secure unless it is encrypted. The ability to siphon data from cellular streams is now becoming easier and cheaper. [↩]