If you're involved in any phase of the payment application development process, this document should be on your reading list.
For anyone involved in the creation of mobile payment applications or uses them as a merchant, it would be beneficial to read these guidelines and understand the effect they may have on a business. In this tip, we'll look at the highlights of the new PCI mobile guidelines and offer a brief analysis for enterprises that have a stake in the mobile payment ecosystem.
What is a mobile payment application?
First, it's important to have a solid understanding of what is covered by the guidelines, which cover any payment application that is designed to run on multipurpose mobile hardware. Translated, this means software that a merchant might use to accept credit card transactions on a consumer-grade mobile device, such as a smartphone, tablet or similar device. Any software designed to run on these devices should be developed in accordance with both the mobile payment acceptance security guidelines and the Payment Application Data Security Standard (PA DSS).
There is one exception to these requirements: payment applications that make use of point-to-point encryption (P2PE) technology to prevent the mobile device from ever having access to cardholder information. These types of payment applications, described in the document "Accepting Mobile Payments with a Smartphone or Tablet," treat the mobile device as an untrusted environment and do not require added security measures.
What do the guidelines suggest?
The guidelines are quick to point out that they are not a comprehensive guide to PA DSS compliance. Rather, they are designed as a mechanism to help organizations interpret the PA DSS requirements in the context of mobile devices. This approach is similar to that used for the PCI DSS Virtualization Guidelines.
The PCI mobile payment guidelines contain three objectives for securing mobile payment transactions:
Objective 1: Prevent account data from being intercepted when entered into a mobile device. If P2PE is not being used, developers must ensure that a secure transmission path exists between the device used to swipe or input card data and the mobile device.
Objective 2: Prevent account data from compromise while processed or stored within the mobile device. Any account data stored temporarily on the device must be protected within a secure storage environment. Data retained on the device after transaction authorization must be protected with hashing, truncation or encryption combined with acceptable key management practices.
Objective 3: Prevent account data from interception upon transmission out of the mobile device. When cardholder data is transmitted from the device to the next step in the authorization process, it must be protected with strong encryption, such as that provided by Secure Sockets Layer (SSL)/Transport Layer Security (TLS).
In addition to listing objectives for securing mobile transactions, the guidelines also include a list of 15 specific points that should be considered when securely configuring the mobile device itself:
- Prevent unauthorized logical device access.
- Create server-side controls and report unauthorized access.
- Prevent escalation of privileges.
- Create the ability to remotely disable the payment application.
- Detect theft or loss.
- Harden supporting systems.
- Prefer online transactions.
- Conform to secure coding, engineering and testing.
- Protect against known vulnerabilities.
- Protect the mobile device from unauthorized applications.
- Protect the mobile device from malware.
- Protect the mobile device from unauthorized attachments.
- Create instructional materials for implementation and use.
- Support secure merchant receipts.
- Provide an indication of secure state.
The guidelines provide additional detail on each of these requirements, as well as suggestions on how devices can be configured to meet these objectives.
What does it mean to you?
The specific responsibilities of each company will vary depending upon its role in the payment application development process. There's a great matrix of the guidelines in Appendix B that offers specific interpretations for device manufacturers, mobile operating system developers, application developers, merchants and mobile payment solution providers.
From the editor: More on mobile payment compliance
For example, a straightforward merchant using technology developed by others would really have no ability to influence the three objectives for securing mobile payment transactions -- those lie within the realm of developers and manufacturers. On the other hand, each organization has specific responsibilities for preventing and reporting unauthorized access to the device and server, detecting the loss or theft of a device, and protecting its devices from malware.
The release of the mobile application development guidelines promises to add additional rigor to the application development process and provide merchants with added assurance that they are operating within the confines of PCI DSS. For anyone involved in any phase of the payment application development process, this document is must-read material.
This was first published in December 2012