Can You Trust it? Mobile Authentication Must Become Context- and Risk-Aware

Enterprises are deploying enterprise mobility suites to manage risks to mobile enterprise content. However, mobile devices can also access sensitive enterprise back-end systems. Security-conscious organizations are now deploying mobile authentication to secure access to enterprise applications and monitor all the transactions that follow, such as updating sensitive financial or business data.

Mobile authentication and access security deal with a fundamental question: Was the authentication or transaction initiated by a genuine employee or customer?

This question addresses two types of threats. First, a cybercriminal could access the user’s credentials (using a phishing attack, for example) and then use his or her mobile device to gain unauthorized access to the enterprise system. Second, a user’s mobile device may be compromised by malware that could tamper with specific interactions created by the genuine user or effectively bypass strong security measures.

Mobile Authentication: The Criminal at the Door

The challenge of detecting a criminal at the door or an account takeover attempt isn’t new. However, mobile devices make that challenge even harder. Historically, risk-based authentication technologies relied on desktop and laptop “fingerprinting” to determine whether a given device had been previously used by the genuine user or whether a new device is being introduced. Step-up authentication measures were triggered for new devices to ensure the real user is using that device.

Unlike desktops and laptops, mobile devices look very similar to server-based device fingerprinting solutions. It is very difficult to distinguish one mobile device from another, especially when iPhones, which are identical within a particular model, are used.

Therefore, mobile access security must evolve to get an accurate device fingerprint that can uniquely identify the device. One way to achieve this is to use a secure mobile browser or embedded mobile risk detection capability within sensitive apps to capture a hardware-based device fingerprint. Used as an access enforcement point, a secure mobile gateway can consider this device fingerprint in conjunction with additional context such as geolocation and time of access to flag or stop high-risk access.

Malware-Infected Devices

A compromised device contains malicious software — or malware — that has privileged access rights to the device’s operating system and core functions, such as SMS. Most mobile malware to date comes packaged into benign applications downloaded from third-party app stores and granted privileged access by the user during the installation process. Similar to phishing, mobile malware can capture credentials and interfere with SMS-based strong authentication by intercepting and redirecting one-time passwords. Another capability that is seen on jailbroken or rooted devices lets malware tamper with transactions on the fly. For example, it could change a payee account in a money transfer.

The Device Is the Weak Link in the Chain of Trust

The ability to trust access depends on the ability to trust the device. Access from a compromised device simply cannot be trusted. By extension, malware and jailbreak detection should be part of the mobile access risk assessment. A device-side component can dynamically detect the state of the device and communicate it to the secure mobile gateway, thus broadening the context used to evaluate the access and enforce corporate policies. Similarly, even if the device isn’t compromised, other contextual data such as location and time of access can help organizations determine whether the access is suspicious and invoke measures to mitigate risk.

Context and risk awareness are key to enabling effective mobile authentication and access security that address risky transactions without degrading the overall user experience. For employees, risk-based authentication can be used to prevent access for devices that are not presenting the proper security posture. Or, if access is allowed, it can restrict specific transactions until the device is brought back to compliance. For customers and other third parties, transactions can be silently flagged for review and the customer service team can follow up on the small subset of activity that exhibits suspicious attributes before it is allowed to execute.

Contributor'photo

Yishay Yovel

Program Director, Mobile and Fraud Strategy, IBM

Yishay Yovel directs IBM Security's mobile and fraud strategy. Yishay was previously the Vice President, Marketing for...