Assuring Quality in Mobile Payments: A Talk with SQS’s Anand Vyas

June 3, 2014 by

Image credit: Primes Inter Pares

Software Quality Systems AG (SQS) is the largest independent provider of software quality assurance and software testing. They recently acquired Thinksoft, a software testing company catering to the financial sector. We spoke with Anand Vyas, formerly of Thinksoft and currently VP of Banking, Financial Services & Insurance at SQS, and go over some of the challenges in making payments secure.

 

Kevin Xu: How will the acquisition further SQS’ goals in promoting security in mobile payments?

Anand Vyas: Thinksoft has lots of software testing experience in this area so is already a pioneer in this particular field. Together, SQS and Thinksoft has an extensive portfolio and deeper combined expertise.

 

What does Thinksoft bring to the table in terms of QA and testing?

Thinksoft has been in the business of providing software testing for some time now so has a strong domain expertise. We push innovation around automation and parameter verification plus mobile testing – including mobile payments – as well as offering our clients a strong offshore capability. This follows the stringent security guidelines in place for mobile payment testing so your data and security are both taken care of.

 

What are your thoughts on open-source software (OSS) in terms of security – following for example, the heartbleed bug in SSL? Do you see financial institutions integrating and testing OSS and, if so, how is it secured?

Whether OSS or COTS is more or less security has been a well discussed over the years and, for one reason or another, at different times, I have sat on both sides of the fence. Today I lean towards the view that OSS isn’t any more or less secure than commercial software. It’s not whether the code is open source or commercial that determines its security, rather I see it as being more related to the level of security focused software assurance methods that are applied during the development lifecycle that make the difference.

For the better part of the past decade, researchers and security experts have all been preaching the Secure SDLC – integrating security testing within the Software Development Lifecycle. Yet, only a few organisations (forced by the standards of their industries) have even begun to consider security a core requirement for software development.

Many have wondered what it will take to make security fundamental to software development; a requirement, not an option. We here at SQS believe the Heartbleed Bug may very well be that event. While SQS cannot speak to the security practices of the OpenSSL Software Foundation, for the sake of this discussion we can presume that, had the Foundation been practicing The Secure SDLC, they could have increased their chances of discovering this bug before it was released to the public at large.

Many financial organisations have already begun their Secure SDLC journey and with open source there has always been the question of support if security issues are identified during assessments. This is probably more true for the more obscure open source projects as the mainstream enterprise-class applications and operating systems have significant backing and support from the likes of IBM and Red Hat. These types of OSS also have a significant track record in business and in government critical systems so going forward I can see financial institutions integrating and testing OSS. The question of how it is secured will really depend on a various factors; such as the type of issue identified by security testing processes, whether the OSS project accepts the issue and agrees to remediate in a reasonable timeframe, can the issue be resolved by the financial institution using external security products, and so on. There won’t be any easy answers to any of this but more often than not getting security issues that have been identified in COTS resolved can also be a challenge.

 

The payments space emphasizes a strong focus on security so quality assurance is a key component. How do you balance consumer experience with security measures?

Experience is critical as you have to test the application and the platform. There is no trade off as both have to be taken into account and considered when designing an application. We focus on providing an end to end service through functional testing, which ensures all of the requirements are the same as those needed by the platform. Then we have thorough testing of usability, functionality, accessibility, performance, and security. We test everything but the designers need to make those considerations first.

 

Anything else you’d like to add?

As we started on the security aspect of mobile payments, I just wanted to say that we believe reliability and security are critical. There are a lot of quality issues around new apps, which could lose you customers. Regaining those lost customers’ confidence and winning them back is a hard task so we advise clients on reliability and security through quality assurance so they are properly covered from day one to avoid risks – both financial and in lost customers. Mobile payments need rapid testing, so testing needs to be significantly reduced where it can be. This is why we advise our clients to use automated testing as it helps them cope with the amount of testing required to ensure an app or platform is secure and reliable.


Anand Vyas, VP of Banking, Financial Services & Insurance at SQS Group
Anand is an experienced leader in IT who is passionate about creating and implementing effective systems to meet challenges in today’s financial sector. Anand has worked in IT for 20 years and has rapidly progressed from software engineer to leading positions in both India and now in the UK.

Anand works for SQS - the world’s leading specialist in software quality. SQS provides solutions for all aspects of quality throughout the whole software product lifecycle supported by a standardized methodology, high offshore automation processes and deep domain knowledge in various industries.

Related Articles