Payment security: The developer's duty
Technology research firm Gartner surmises that 75% of mobile applications failed basic security tests in 2015. That’s a particularly troubling statistic for retailers, who are deploying payment-enabled mobile applications en-masse. It’s equally troubling to the developers that are outfitting merchants with those payment applications, because the threat is far from contained. Earlier this year, the McAfee Labs Threats Report identified more than 6 million samples of mobile malware, up from just 1.5 million in Q1 2013. In its report, McAfee identifies poor programming practices by application developers that expose users to a variety of SSL/TLS (secure socket layer/transport layer security) vulnerabilities such as BERserk and Heartbleed as the primary culprit.
It’s clear that hackers are taking advantage of unsecured mobile apps and public Wi-Fi networks—both of which are experiencing explosive growth right now— to break into not just the valuable data on retail mobile devices, but within the broader retail network. In a collective haste to rush mobile applications into the hands of consumers, merchants are leaving that door wide open to cybercriminals. In fact, a 2015 survey commissioned by IBM and conducted by the Ponemon Institute found that:
- The average company tests fewer than half of the mobile apps they build.
- A third never test their apps at all
- Organizations spend an average of $34 million annually on mobile app development, but only 5.5 percent of that budget is being allocated to securing mobile apps against cyber-attacks before the apps are taken to market
- Half the surveyed companies don’t allocate any funding at all for mobile app security
As merchants and consumers alike become more aware of the growing risks associated with mobile applications—specifically those that are payment- and customer data-enabled—developers and ISVs are being pressured to ensure that security is “baked into” their applications. Payment-enabled mobile applications are running rampant in retail, and their security is of profound importance to developers and ISVs.
The Five Fingers Of Payment Application Security
For a payment application to be deemed PA-DSS (Payment Application Data Security Standards) compliant, the PCI SSC (Payment Card Industry Security Standards Council) mandates developers to ensure that their applications include the following protections:
- Do not retain full magnetic stripe, card validation code or value, or PIN block data.
- Protect stored cardholder data.
- Provide secure authentication features.
- Log payment application activity.
- Develop secure payment applications.
- Protect wireless transmissions.
- Test payment applications to address vulnerabilities.
- Facilitate secure network implementation.
- Cardholder data must never be stored on a server connected to the Internet.
- Facilitate secure remote software updates.
- Facilitate secure remote access to payment application.
- Encrypt sensitive traffic over public networks.
- Encrypt all non-console administrative access.
- Maintain instructional documentation and training programs for customers, resellers, and integrators.
That’s a long list of regulations, which often take a back seat among developers whose primary concerns are minimizing the impact of their applications on the POS and the merchant/consumer experience. But the dichotomy between the aforementioned research on the integrity of application security and the payment application development requirements put forth by the PCI SSC couldn’t be clearer. Ironically, the majority of these requirements can be met quite simply by enlisting the five “fingers” of payment security:
- EMV to authenticate the card is not counterfeit
- End-to-end encryption (E2EE) to protect the transmission of data
- Tokenization to protect stored data
- PCI to protect consumer data
- Anti-fraud services to proactively address payment anomalies
Of course, these five elements aren’t all the sole responsibility of the developer. A secure payments environment is the product of a collaborative effort among developers, software vendors, dealers/integrators, acquirers, and merchants. For their part, developers can ensure EMV readiness, E2EE, and tokenization are “baked into” their applications by working with a merchant acquirer that offers integrated payment solutions. That’s key to the success of developers, dealers, and merchants. Payment engines with proven integrations to hundreds of POS systems of record—and those that can demonstrate success driving new, in-demand payment types—minimize update disruption at the POS, thus minimizing operational disruption for the merchant.
Self-Management of Security a Viable Alternative?
The realities of the state of application security indicate that many developers and ISVs simply aren’t taking security requirements into account on their own accord. That’s not necessarily a product of ignorance. Achieving the application security requirements set forth by the PCI SSC requires considerable investment, time, and expertise. To do it on their own, ISVs must research and provision the technologies that enable security, build them into their applications, and support them independently. That’s a difficult and expensive pill for developers—who are focused on improving application user interfaces and developing the “next big thing”—to swallow.
Still, retailers and consumers alike are increasingly demanding highly-secure applications, which makes security a cornerstone of the developer’s value proposition. As mobile application security continues to enter the market’s collective consciousness, those developers who employ standard security protocols will differentiate their offerings and end up the winners in the long run.
To get there, many ISVs and developers are finding it attractive to work with a merchant acquirer that can save them from the overhead and expertise associated with aggregating secure technology protocols on their own, and that embrace support of mobile payment applications on the back end. Those developers are realizing the value of partnering with an acquirer that offers an appropriate level of security for the application’s use case based on the five fingers of security, one set of services through unobtrusive integration, and managed security support and services throughout the application’s lifecycle.
While a secure mobile payment application will ensure the sustainability of your business, security isn’t a profit center for most mobile application developers. Partnering with a merchant services provider that offers seamless, invisible mobile payments execution through an embedded browser in the POS—while simultaneously handling payment data encryption and tokenization—allows application developers and ISVs to focus on the merchant/consumer experience that drives sales.