Consumers increasingly rely on their handheld or tablet devices to carry out everyday tasks while on the move. It is no surprise that the mobile payment (m-payment) industry is experiencing exponential growth to meet this change in behaviour. Gartner predicts that in 2016 there will be 448 million m-payment users, in a market worth $617 billion.
To address concerns around m-payment and the integrity and security of cardholder and personal data, in September 2012, the Payment Card Industry Security Standards Council (PCI SSC) issued the first version of the security guidelines for developers of mobile payment applications. These guidelines turn a spotlight on the developers, banks and organisations involved with development of mobile payment applications and whether they are meeting the security and data privacy needs of consumers.
It's clear that rapid changes in the mobile payments market are underway. What should the PCI SSC take into consideration within its guidelines, and who should ultimately have responsibility for the security of these payment methods? Organisations and developers should be taking proactive measures at the outset of any application development, including the need for threat analysis, vulnerability assessment and best practice guidelines in lifecycle management, to ensure that there are proper safeguards in place.
The rise of m-payments and the PCI SSC
The Payment Card Industry Data Security Standard (PCI DSS) will fundamentally change over the next few years. Visa's Technology Innovation Program (TIP), Point-to-Point Encryption (P2PE), and near field communication (NFC) and mobile payments (m-payments) have all opened the door for not only a more risk-based approach to PCI DSS, but for a total shift away from the credit card paradigm. Everyone from smartcard vendors, to mobile network operators (MNOs), to payment service providers (PSPs) and existing payments networks all want their piece of the pie. Combine this with the launch of services such as Google Wallet, the EU's imminent approval of a mobile payment hub, and the raft of new handsets featuring NFC, and the question of how to protect the consumer from a security standpoint is brought into sharp focus.
The PCI SSC has begun issuing guidance to those involved in the payments ecosystem. The aim of recent mobile security guidelines was to educate the stakeholders responsible for ‘the architecture, design and development of mobile apps and their associated environment'. Yet will the guidelines be able to keep up with the market demands and emerging threats? Due to the nature of mobile devices today, any threat that exists for a computer will exist for a mobile device, resulting in a vastly increased exposure to data theft.
Building security in at the outset
Mobile payments can take many forms; from external swipe devices (such as Square), to e-wallets (payment details stored online), to apps that store payment details in the mobile application itself. Understanding how the payment data is to be collected and encrypted is fundamental to choosing the security measures commensurate with the risk inherent to each service.
While there are many parties involved in the overall security of a mobile device, where in the process does the security of an application come to the fore? The need to protect and secure customer's data and personal information is paramount for all businesses with regards to their existing IT infrastructure, yet is the same true for the mobile applications? The need to issue new applications that work with the latest devices and operating systems faster than competitors has resulted in security taking a backseat in the development of an application; putting customer security and data at risk.
If m-payments are to take off as forecasted, the development focus needs to change so that security is ultimately part of the initial requirements analysis and that the use of customers data is either minimised, adequately encrypted or (preferably) both. This oversight needs to be addressed on two levels:
1. With the PCI SSC leading the charge with a series of best practice guidelines and enforcing regulations (something that would be difficult to do and achieve)
2. By educating and training developers on fundamental secure coding principles.
At the outset of the development of an application, the developer is briefed as to the specifications required. However, this often only includes the desired functional result, and does not include sufficient security measures and milestone checks. As a result, the application is typically launched before even the most basic security measures are included, and often included as an afterthought. These are seldom sufficient, and counterproductively, may even interfere with the desired function or look of the original application. The knowledge of security threats and risks is something in which few developers are trained adequately, however the PCI SSC are recommending that application developers should be trained on the requirements within PCI standards in order to meet the minimum criteria needed for possible future accreditation.
What do developers need to know? They should have training covering the full security ecosystem – from threat analysis, to lifecycle and vulnerability / patch management. This knowledge will ensure that the correct procedures and measures are in place to help prevent unauthorised access to the application, detect theft or loss, protect against known vulnerabilities and malware and mitigate the risk posed by unauthorised attachments. All while conforming to secure coding, engineering and testing procedures as outlined in the Payment Application Data Security Standard (PA-DSS).
There should be a process put in place for the discovery and evaluation of any new threats so they can be mitigated before they become an issue. By adopting these measures, a developer will have the knowledge and understanding of how to incorporate security into the applications' functionality desired by their employer or client.
Ensure security is not an afterthought
Working in tandem with this rigorous training must be the need for best practice guidelines. These are used to measure the security and development of an application. Currently there are few, if any, standard measurements for benchmarking application security during development. With the exception of the new, and granted, somewhat immature PCI SSC mobile recommendations, these will struggle to keep up with the developments in technology and security threats. The industry needs to come together to ensure that security is at the forefront of the development process with recommendations on topics such as outsourcing and controls to ensure that the authentication for transactions is secure.
What is needed is a standardised framework, whether in conjunction with the PCI SSC or not, to help guide the industry as a whole and protect all stakeholders in the process – especially our customers. This standardisation is a step in the right direction to give customers a sense that their data is as protected on their mobile applications as it is online.
David Froud is global director of practice development at Trustwave