Mobile Payments is one of the most popular Payment Card Industry (PCI) topics CI-related discussion topics that we’ve discussed with our retail clients over the past year. Many of these merchants have been working on creative solutions to enhance their customers’ shopping experience. In May 2012, The PCI Standards Council (PCICo) released an “At a Glance” document entitled, “Accepting Mobile Payments with a Smartphone or Tablet.” The purpose of this two-page document is to provide guidance to those merchants interested in implementing mobile payments at their retail locations. While this document does not set any new standards in stone, it does provide some pretty strong direction, and perhaps some insight pertaining to the future of the PCI Data Security Standard.
The document points us down two paths to the same end-point – the end point being that the mobile device should be taken out of scope by encrypting cardholder data (CHD) at the swipe through an approved PIN entry device (PED) or through an Approved Secure Card Reader. The two paths to achieve this solution would be for the merchant to partner with a PCI P2PE (point-to-point encryption) validated Solution Provider or to implement their own solution by using an approved POI (point of interaction) device. Reader, take note: While it is not a PCI requirement to encrypt the cardholder data before it hits the mobile device, it sure is a good idea. Why?
1) It is difficult to configure managed mobile devices such that they would be considered a “trusted platform.”
2) Many of these devices are consumer-oriented and not meant to be managed or locked down at a corporate level.
3) There is a general lack of guidance or security Best Practices pertaining to how to properly secure these devices. There is a lot of “we don’t know what we don’t know.”
4) There are the ever-increasing threats of cyber-crime on mobile devices. (See the recent article in Digital Transactions magazine.)
5) These devices are portable and easily stolen (which may allow an attacker to obtain CHD, decryption keys, or code).
6) Sensitive data may be leaked through potentially covert channels, such as Bluetooth or 3/4G.
7) Not all mobile applications were well planned or written securely. Conversely, some were written securely but were implemented poorly.
Given the proliferation of mobile devices, along with the ever-changing landscape of these devices, it makes good sense to adhere to the KISS (keep it simple, stupid) principle and just encrypt CHD at the swipe (assuming that the device through which the encrypted CHD does not have the ability to decrypt it). This renders the mobile device out of scope, therefore dramatically reducing the level of effort an organization must undertake in order to protect CHD on the mobile device itself.
Do you have to implement one of these two general solutions to be PCI compliant? No, but if you don’t the burden will then be on you to demonstrate that your mobile acceptance solution meets the intent and rigor of protecting CHD. This would include, but is not limited to:
- Secure build and hardening (PCI DSS requirement 2.x).
- If the device must store CHD, you must use strong encryption and key management (requirement 3.x). I’d strongly recommend against CHD storage of any kind on a mobile device.
- Strong wireless configuration (PCI DSS 4.1.1). Also, the need to lock down communication channels.
- Anti-malware (PCI DSS 5.x) – to the extent it may apply to a particular device.
- Patch management (PCI DSS 6.1 and 6.2).
- Penetration testing (PCI DSS 11.3) – note that pen testing will require a pen tester who is well versed in pen testing mobile devices, which may be a different skill set than other types of pen testers.
- Policies pertaining to the use of mobile devices (12.3.x).
- How to address lost or stolen devices.