Ask a QSA – Mobile attack rates: how can your business customers better secure their m-commerce channel?

0 Shares
By Sam Pfanstiel, QSA, QSA(P2PE), QPA, PA-QSA, SSF, SSA, SSLCA

Ask a QSA recently received the following query from an acquirer and we felt that this may be of interest to our readers. Merchants had been asking their acquirer how can we better secure our m-commerce channel?

It’s a good question. Recent research has shown that mobile attack rates are on the increase with mobile transactions now topping desktop transactions as mobile devices are an enabler to the ‘always-on, always-there’ culture of goods and services today.

Mobile attacks over the last year have included account login fraud, account creation fraud and payments fraud. Using stolen or harvested credentials, criminals can commit a variety of other fraudulent activity including ‘legitimising’ activity to obtain other credit cards, benefits and generally misrepresent identity.

Many merchants are now developing applications (app/apps) with payment facility for their consumer base to run on the consumer’s device (e.g. smartphone, tablet or laptop).

So, if a merchant does develop an app, what are the important things for them to consider?

Firstly, it is important for the merchant to consider their obligations for their in-house payment app in terms of PCI DSS and for certification as a payment application under either PA-DSS (the Payment Application Data Security Standard) or SSF (the Secure Software Framework). The PCI SSC advises that if the app user is also the cardholder, and using the app for their sole purpose, then the device is treated similarly to a cardholder’s payment card but outside of the scope of these requirements.

That said, even though the consumer’s device is outside of the scope of PCI DSS, the development of that application should still be developed in accordance with industry best practice such as ENISA and OWASP as well as PCI DSS requirements 6.3, 6.4 and 6.5. Further advice and guidance for developers can be found in the PCI Mobile Payment Acceptance Security Guidelines for Developers.

Secondly, although there may be no PCI DSS compliance obligations (as a merchant has no control over the consumer’s device and no cardholder data environment to implement/operate PCI DSS controls for) it is probably better not to use an ‘in-app’ method of card data capture. Instead use developer created forms and code that rely on the payment being fully outsourced to a PCI compliant Payment Service Provider (PSP) to capture the card details. For example, some methods can link the app to the PSP’s hosted payment page, or like the Stripe -Braintree, and Adyen iOS and Android examples where the developer can embed card input widgets from these third parties.

Some excellent resources available to developers of mobile applications which merchants may wish to discuss with their developers can be found here:

Stripe:

Braintree:

Adyen:

Some other things to consider include:

  • Develop a mobile-friendly app for customers to register and use for transactions. This allows for some online behaviour to be captured building a profile of the customer that includes, a history of normal and potentially abnormal behaviour as well as their device history (see fingerprinting below).

  • Utilise device ‘fingerprinting’ to interrogate and capture device-specific information from the customer’s mobile device, such as the make and model of the device, its build number or version, it’s International Mobile Equipment Identity (IMEI), Mobile Equipment ID (MEID) or Unique Device ID (UDID Apple devices) number and even its actual mobile phone number.

  • Ensure that the app requires the use of strong end-to-end encryption to protect the customer data as it moves from the app on their mobile device to the business or payment service provider.

  • Ensure the use of strong encryption for any personal data that might be retained within the application.

  • Consider setting the app to check if the device has been jailbroken or rooted to avoid introducing risks. For further advice and guidance on this see mobile application security

  • Use an out-of-band identity verification method when the user is creating their account for the initial setup

  • Implement 3-D Secure version 2.0 within the checkout page for those transactions that warrant its use. PCI has recently begun listing certified 3DS SDK providers.

  • Ensure rigorous penetration and user acceptance testing of the application

What about mobile wallets, mobile POS and other mobile payment applications?

For most merchants, the goal is to provide an app that is loaded onto a single consumer’s mobile device, and interact with a single card, as described above. However, some larger merchants or technology providers may wish to develop mobile apps to run on the merchant’s devices, which will collect credit cards from many customers.

This mobile point-of-sale (mPOS) apps fall under the scope of PCI DSS and payment application compliance programs. In addition to the best practices above, there are a number of application standards that will come into play, including the following

  • PCI DSS – Since the device exists within the merchant’s cardholder data environment (CDE) it must be assessed as part of the merchant’s annual PCI DSS assessment.

  • Software Security Framework – This set of compliance standards is replacing PA-DSS, and it includes both Secure Software and Secure Software Lifecycle standards. Your mPOS solution must be certified with your acquirer, and they will insist that your application be assessed against either PA-DSS or SSF Secure Software prior to certification.

  • Point-to-Point Encryption – Where it is possible for the mobile device (such as a smartphone or tablet) to operate as the point-of-sale, thereby facilitating a transaction that is captured in a payment terminal (such as a countertop PIN pad), providers should consider the PCI-P2PE program as a means of increasing the overall security of their solution, and avoiding many of the compliance requirements associated with PCI DSS and SSF.

  • Software-based PIN on COTS – For mPOS solutions that accept PIN entry on the mobile device, this standard (abbreviated SPoC) will be required to ensure protection of the customer’s PIN.

  • Contactless PIN on COTS – This standard, abbreviated CPoC, is designed for mPOS solutions that accept NFC direct transactions using transceivers within the mobile device.


Contact Sysnet for assistance in obtaining these certifications for your organization.

Like this Article?

Subscribe to receive more tips & news about Cyber Security, Compliance and a lot more!

  • Sysnet Global Solutions will use the information you provide on this form to be in touch with you regarding non-promotional as well as promotional material by email and phone. If you agree to same, then please select the ‘I consent’ box after reading the terms and conditions listed below in relation to consent. You can change your mind at any time by clicking the unsubscribe link in the footer of any email you receive from us, update your preferences for communications, content etc. by clicking on the update my preferences button in any email we send you or by contacting us at marketing@sysnetgs.com We will treat your information with respect. For more information about our privacy practices please visit our website. By clicking below, you agree that we may process your information in accordance with these terms. We use Pardot as our marketing automation platform. By clicking below to submit this form, you acknowledge or agree that the information you provide will be transferred to Pardot for processing in accordance with their Privacy Policy and Terms