Data Tells All

• By Danny Piangerelli
• Apr 01, 2016

The public has spoken. It is clear as day. Mobile is winning. People are increasingly using on-the-go applications in their everyday lives. Engaging with it. Relying on it. The data is also in, and it’s more than compelling. Back in 2014, CNN Money reported that, for the first time, mobile Internet usage had reached 55 percent, indicating that mobile Internet usage had finally surpassed desktop Internet usage.

Of the 55 percent using mobile, 47 percent of the traffic came from apps, with eight percent coming from mobile browsers. Google also recently made news when it confirmed that for the first time in the company’s history, it was seeing more overall searches conducted on mobile devices than on desktops. The Rise of Mobile and Consequent Security Issues As mobile usage continues its unprecedented rise, the same security concerns that required so much focus and attention during the PC-era are resurfacing. While some issues are common, such as data transmission and malware, others are relatively new to the mobile space, such as device considerations. Particularly interesting is, though initially brought to light on mobile, some advances around securing the mobile device have even made their way back to PCs and traditional desktops, such as sand boxing of applications and improvements in biometric technology.

The current state of mobile security is hard to detail completely, but there are certainly some common themes. System vulnerabilities continue to be a major cause of concern. In 2015, CVE Details, an online repository for reports of vulnerabilities, reported that 375 vulnerabilities were disclosed on iOS, and 130 on Android. The severity and proliferation of these vulnerabilities vary greatly, but the fact remains that even with mature mobile operating systems such as these, the potential for vulnerable code to make it into production is still high. Users also continue to contribute to the problem. There is still a market for users who want to jailbreak or root their devices, sometimes without knowing that doing so greatly increases their risk because they break the OS manufacturer’s built in security controls. Also, while these operating systems and apps appear to be updated by developers on a relatively frequent basis, users don’t seem to be as diligent about updating their operating systems and apps. In the Android space, OEMs and carriers are exacerbating the problem with slow adoption of new updates from Google.

Some users are bypassing instructions from Apple and Google to only download apps from the officially sanctioned Apple App Store and Google Play stores, and are instead downloading apps from third-party sources, thereby bypassing Apple and Google’s safeguards. In most cases, users who unknowingly infect their devices with malware are doing so by downloading seemingly legitimate apps from those third-party sources. Even within the relatively malware free Apple App Store, a series of apps were found to be infected recently with malware. While the apps were legitimate with the app developers unaware of the malware, it was those same app developers who created the problem, in this case by developing and building the apps submitted using an unauthorized copy of Apple’s XCode development toolset.

While the existence of malicious apps continues to remain a concern for many, potentially the most serious threat to mobile security is found within legitimate, in some cases popular and heavily downloaded, apps. Insecure coding practices of some app developers are unwittingly causing a serious condition in some apps. Known commonly as “leaking data,” these apps are allowing sensitive data into potentially dangerous hands. Sometimes apps are found to house data that is used internally within the app, and that data is not considered sensitive. This might include fonts and game state information. In other cases however, sensitive data, such as passwords, social security numbers and banking information is either stored insecurely in the device or transmitted insecurely.

Recently, NowSecure, a Chicago-based mobile application security firm, published the results of an investigation of its extensive internal database of app vulnerabilities. The firm’s focus was on the issue of apps “leaking” sensitive data. They found that 11 percent of the Android apps leaked sensitive information; 25 percent of Android apps tested had at least one high-risk vulnerability. They additionally found that 35 percent of mobile data tested appeared to be sent unencrypted.

Statistics such as these reveal the lack of standard secure coding practices within portions of the app development community. Security as part of the SDLC and frequent app vetting and testing are standards that should be adopted by any app developer, whether in one of the more traditional “high security” verticals, such as banking, or otherwise.

Biometrics: Security at Your Fingertips?

One of the newest areas of interest within the mobile security conversation is biometrics. Though some form of experimentation has existed for some time, Apple’s inclusion of TouchID in the iPhone 5s hardware platform effectively brought biometrics to the forefront of consumer adoption. By giving users a seamless and elegant way of securing their devices using data derived from their fingerprints, and storing that data within a Secure Element on the device, Apple proved that biometrics need not be as invasive and complicated as originally feared. Many apps made use of this functionality, allowing users to secure their apps with the TouchID element.

Since the TouchID element only indicates to an app that the user touching the sensor has a fingerprint registered on the device, it does not necessarily replace a more thorough authentication method for more security sensitive applications. For those applications, the TouchID authorization from the device should be used as a second or third factor of authentication, in addition to traditional methods such as user name and password, to ensure that the sensitive data is not ever required to be stored on a device.

Other forms of biometric advances being implemented today involve voice and eye recognition. In both cases, several vendors have created apps and SDKs for inclusion in other apps that make use of the microphone and camera on the device to, much like TouchID, create a data representation of the user’s voice or, in the case of EyeVerify’s eye print technology, the blood vessel architecture of the user’s eyes. This technology uses pattern matching algorithms to determine whether or not the sensed user is the registered user for that particular application.

Exploring Behavioral Analytics

One of the most exciting new areas of interest within the broader biometric conversation is what is commonly being referred to as “behavioral analytics.” Common in the anti-fraud space for years, behavioral analysis techniques are now being systematized and applied to real-time analysis within mobile apps, using primarily the device’s extensive sensor information for the raw usage data.

Security firms such as BehavioSec and Crysp are reporting between 75 percent and 95 percent accuracy rates in establishing a user’s identity based solely on the usage of a particular app with their sensing technology embedded. Though there are several analysis techniques, a typical one involves an extensive analysis of the user’s typing cadence when entering data within a text field. There are a surprising number of characteristics that can be derived from simple character entry within a data field.

Behavioral analysis indicates a much more interesting future for security and analysis. Because of the ubiquity of mobile, a much better determination of an end user’s behavior can be established by the device being with the user at all times. Though privacy concerns will remain an issue, the information collected and analyzed does not contain personally identifiable information.

Here’s an example of how a user’s identity can potentially be derived from behavioral factors. The user name and password fields are tagged for inclusion in the analysis. As the user types his or her username, several factors based on touch are logged, such as the “flight time,” the milliseconds recorded between touches. Key pressure is also logged, which tracks exactly how much pressure the user is applying to the screen for each touch. Additionally, key press time can be logged, which tracks how long a user touches a particular screen element. These three factors alone, taken in aggregate, over a relatively short period, can be used to add to what is commonly referred to as a user’s “context.” In this case, the context contains a wealth of knowledge already, based only on the key presses that a user has conducted.

In addition to the user’s context are factors that come from the device, but may not be derived simply from text input. For example, the gyroscopes on the device are used to determine the most common angle the user holds their device when interacting with the app. The GPS sensor is used to establish common locations where the app is launched. What is especially interesting around location is that because of the mobile nature of the device, it is unlikely that a user would always interact with an app in any one setting.

Additionally, if a wearable device is registered and using the same mobile app, then another set of data points can be added and compared to the mobile device’s usage, such as the phone. Is the watch app’s usage pattern consistent with the phones? Did the most recent balance transfer, for example, initiated on the mobile phone take place in a location that is dramatically different from the watch’s location? A proper behavioral analysis of the user’s location data would determine, over time, that several key locations are being used more regularly, and the newer locations can then be added as “safe zones” to the user’s context. For example, if the mobile banking app’s debit card on/off feature consistently shows that a card is enabled and disabled at the same several key locations, such as a Big Box store, when the app detects a new location, but also a Big Box store in the general area, then the addition of this zone to the user’s context could require less overall analysis because of the likelihood of the situation.

An Updated System

Other factors are added to the context that can come from the device’s configuration. For example, after months of usage logged, suddenly the device is showing a jail-broken status. Or has the operating system been updated? Because the data is collected, aggregated and analyzed with trends in mind, no single factor will immediately skew the results. In the operating system scenario above, it is very likely that an iOS user would update their operating system at least once a year when a new version is released. In that case, as in all of the analysis cases, a follow up authentication step can be used to further authenticate the user. The behavioral analysis can be used to inform the session, but does not have to be the only factor used to determine identity.

All the other factors remain, but the behavioral piece can be used to augment the factors used. Additionally, behavioral analysis does not require enrollment. This is a vital point, because, unlike voice and facial recognition, which require some element of user enablement to “register” the factors, behavioral techniques rely on usage, which is obviously already happening without the user needing to establish anything at all.

As the security landscape continues to evolve, the app development community continues to evolve concurrently. The threats certainly remain and will continue to exist going forward. The usage of mobile devices will continue to grow, as will their natural extension into wearables, which ultimately are similar if not identical to mobile devices in terms of threat vectors.

What is unique about the wearables and mobile devices is that they also afford users and app developers more information that is more uniquely relevant to the end user, which cannot easily be replicated. Apps that learn about their users, and offer those users unique experiences, are already present and growing. Some of those same techniques can and will be used to help users protect themselves, as well as their data.

This article originally appeared in the April 2016 issue of Security Today.