Object reference not set to an instance of an object.

Led by a sharp rise in the number of mobile subscribers globally, and the high volume of smartphone sales, mobile payments (m-payments) are expected to exceed £429 billion by 2017. And now, with the UK nationwide launch of ‘Paym’, Paypal, Apple, Google, and providers such as AT&T and Verizon embedding ISIS into the software provided on their devices with NFC chips, I expect the trend to pick up quickly. Facebook is also now rumoured to be ready to enter into the mobile payment space. MasterCard tracks mobile payment readiness by country, with Singapore, North America and Kenya leading the charge with an over 40% adoption ready-rate.

The complexity of the mobile supply chain and its ecosystem presents major challenges. With large amount of sensitive information available via mobile devices, any weakness in m-payment systems‘ securities provides opportunities for skilled and well-resourced cyber-fraudsters and criminals. Apart from eliminating these threats, all parties need to consider an approach to testing and quality assurance which focuses on security and is designed to help reduce potential exposure to risks. Therefore the importance of embedding security testing into the SDLC is prevalent now, more than ever.

There are, in my opinion, several key aspects of conducting security testing against mobile applications to ensure proper security controls have been implemented. While mobile applications should follow a similar security testing model as Web-based applications, there are a few variances that should be taken into consideration. The diversity of devices, operating systems and network environments can provide challenges when conducting mobile application testing, due to the various attack vectors available.

One of the key ways to get in front of the diversity is to define the security requirements at the onset of products design. This can be accomplished by performing a Threat Modelling project when the product is in its planning phase. During the Threat Modelling phase the product, including the data type(s), risk and threats, environment, and required controls are all documented and planned for.

In addition, conducting a Static Application Security Testing (SAST) (also known as Static Code Analysis), can be done quite easily on mobile applications. This is due to the fact that mobile applications, from a coding perspective, are typically small when it comes to lines of code. Therefore, performing it at various checkpoints in the SDLC can take less time than a standard web application, but can provide high return in value when it comes to identifying security vulnerabilities early in the development.

Dynamic Application Security Testing (DAST) is another form of security testing that evaluates the software at the Application Layer, versus SAST, which is at the code layer. When DAST is taking place, minimal new security related vulnerabilities should be identified.

In summary, while the adoption of mobile payments globally varies greatly, and despite slower growth than previously expected in certain markets, the importance of providing security requirements into the product design cannot be minimized. By embedding security testing into the Software Development Lifecycle (SDLC) of mobile pay now, companies can ensure customer retention and loyalty by winning their trust, the viability and value of their product design in the future.