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
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
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
This article originally appeared in the April 2016 issue of Security Today.