Using a personal mobile device for financial transactions exposes enterprises to risks that most cannot detect and prevent. This is mainly due to the inability to transform traditional access services to adapt to the mobile threat landscape while maintaining a delivery speed that can compete with their peers and is expected by their clients.

The transformation of application delivery approaches always introduces new vulnerabilities, but mobile transaction security demands a new perspective. Since app response time is a key indicator of mobile app competitiveness, design processes are pushing executable functions to the device itself, which exposes new exploit vectors to the attacker. Previous discussions have focused on protecting internal networks from malware hosted on enterprise mobile devices, so this article will consider the threat from the perspective of delivering consumer transactional apps.

Federal Reserve banks across the globe are simultaneously pushing for real-time payment processing. This pushes additional responsibilities on fraud teams to detect and prevent credit card and ATM fraud in near-real time. Remediation processes that banks relied on to recover fraudulent fund transfers in the past are being removed, so they must determine how best to detect fraud that is occurring at the time of the transaction. Such a mandate puts a premium on having intelligent fraud detection systems in place across the full breadth of consumer access services. Fraud detection is now required to adapt at Internet speed to threats present in traditional Internet and mobile access channels. With the accelerated use of mobile for online transactions, transaction processing through the Internet must be adapted and, in some cases, transformed.

Authenticity of the App

It is typical for security vendors to introduce mobile app protection as an extension of enterprise vulnerability scanning techniques. However, a larger percentage of functionality is embedded within the mobile app so it can interact directly with features of the device itself. Features such as geographic location, token storage mechanisms and fingerprint readers can be used within a mobile app. Such an approach has taken a level of protection that traditional Internet browsers provided, and this aspect is easily overlooked by service delivery teams. Leakage of the app functionality to a malicious individual reveals intelligence about how the app itself is designed and operates at runtime. This exposes the internal workings of the app code and enables an attacker to access, modify, rebuild and deploy without the transaction service being aware. Addressing this risk requires an approach that ensures that cannot be modified.

Trustworthiness of the Device

This mobile app code must support a broad range of devices, each running potentially different operating environments. This results in the app being exposed to a broad range of potential vulnerabilities across the support devices. Although Apple provides regular, consistent updates for the Apple device ecosystem, the same can’t be said for Google’s Android. This fragmentation creates an opportunity for attackers to target operating systems running on devices where known vulnerabilities remain unpatched. Even with Apple devices, it is well known that owners jailbreak their devices so they can run unverified app code or access traditionally locked-down device capabilities. Therefore, a device’s trustworthiness must always be questioned. The ability to assert the trustworthiness of a device is vital for addressing mobile transaction security concerns.

Identification of the User

Finally, there is the identification of the user. In the Internet age, the industry was unable to satisfy the need for risk-based authentication assurance policies that reflected a real-time transaction being performed. This is largely due to the lack of options provided by browser-based solutions. However, mobile device capabilities expose features that enable stronger authentication patterns that appease customer usage preferences. Binding a user through a known single password to a previously registered device is becoming a widely accepted baseline for low-value mobile transaction security policies. At the lowest level of assurance, the user of a registered app (without presenting the single password) can grant basic read-only access to financial data. This design approach has provided a significant improvement in user satisfaction for enterprises that have delivered graduated authenticated capabilities to enable swipe-for-balance and PIN-based authentication mechanisms for higher-level access.

Enterprises that provide mobile transaction security need protection mechanisms in place that consider these three key aspects. Before allowing access or transactional execution, authorization decision processes must be adequate enough to counter the threats represented not simply by one of these vectors, but the combination of all three. A risk-based methodology for acting upon unscrupulous behavior is required at runtime.

Mobile Transaction Security Offerings

The following are three well-defined cybersecurity domains that must be integrated together to provide a framework for implementing end-to-end mobile transaction security:

  • Access Management: A set of services that, among other capabilities, provide authentication and user context-based decisions for Web and RESTful Web services. When used with the aforementioned capabilities, products in this domain must provide the risk-based framework for authorizing users on devices using particular app code to perform transactions. It must provide this capability along with a set of industry-standard authentication mechanisms for authenticating users.
  • Fraud Protection: Fraud protection services ensure the status of the connecting device is known. This includes the identification of an individual device and attributes of the device, such as jailbroken, rooted, malware infection status, installation of rogue applications and the use of root-hiding tools. It provides quantitative, risk-based trustworthiness metrics that reflect the device’s operating state.
  • Application Security: Application protection wraps the app code to ensure executable code authenticity — i.e., the app being used on the device has not been tampered with.

When combined with secure data transit and flows, the question of whether a user should be able to perform a transaction using code running on a particular device can be made with confidence. Without one piece of the puzzle, enterprises simply can’t have the confidence to proceed without avoiding risk.

Read the Ponemon Study on the State of Mobile Application Insecurity

More from Application Security

What’s up India? PixPirate is back and spreading via WhatsApp

8 min read - This blog post is the continuation of a previous blog regarding PixPirate malware. If you haven’t read the initial post, please take a couple of minutes to get caught up before diving into this content. PixPirate malware consists of two components: a downloader application and a droppee application, and both are custom-made and operated by the same fraudster group. Although the traditional role of a downloader is to install the droppee on the victim device, with PixPirate, the downloader also…

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today