The Darkside of Mobile Applications

July 2011
$99

Analytics.InformationWeek.com

F u n d a m e n t a l s

Dark Side of Mobile Apps:
K e e p i n g D at a S a fe o n t h e M ove
Companies are rushing headlong to develop applications
for mobile customers who frequent app stores for Android,
Apple and BlackBerry devices. But amid the flurry, IT must
maintain its secure software development lifecycle process,
including client-side, transport and Web application
security strategies, or risk a black eye.
By Adam Ely

Report ID: S3060711

Dark Side of App Stores
A n a l y t i c s . I n f o r m a t i o n We e k . c o m


CO NTENT S 3 Author’s Bio

4 Security at the Speed of Innovation

4 Figure 1: IT-Supported OS Platforms

5 Faster Isn’t Always Better

6 Figure 2: Top Concerns With Growing Number of Devices and
Operating Systems
F

7 Where the Risks Are
O

9 Platform Peril

9 Figure 3: Active Monitoring of Remote PC and Mobile Device Access
E

11 Adapt and Adjust
L

11 Figure 4: Standard Configuration for Personal Mobile Devices
B

12 Selective Review
A

14 Related Reports
T

ABOUT US | InformationWeek Analytics’ experienced analysts arm business technology
decision-makers with real-world perspective based on a combination of qualitative and quantitative
research, business and technology assessment and planning tools, and technology adoption best
practices gleaned from experience.
If you’d like to contact us, write to managing director Art Wittmann at awittmann@techweb.com,
executive editor Lorna Garey at lgarey@techweb.com and research managing editor Heather Vallis
at hvallis@techweb.com. Find all of our reports at www.analytics.informationweek.com.

2 July 2011 © 2011 InformationWeek, Reproduction Prohibited



Adam Ely is director of security for TiVo. As an InformationWeek
Analytics contributor, he has authored multiple research reports
on data and code security. He previously led a software develop-
Adam Ely
InformationWeek ment group at Walt Disney Co., where he implemented secure
Analytics coding standards and source code analysis processes.

Adam gained extensive experience with enterprise and cloud security while
supporting applications and services for clients such as AmEx, Citi and
Expedia as manager of information security with TRX. He has published
numerous security vulnerabilities and papers and conducts security
research with leading firms to advance threat analysis and protections.

Adam currently serves as a member of the Journal Editorial Review
Committee for ISACA and sits on the advisory board for an information
security consulting firm. He has released numerous application vulnerabili-
ty advisories, authored and contributed to open source security applica-
tions, and is the co-author of the Center for Internet Security Tomcat
Benchmark. He holds an MBA from Florida State University; a BS in infor-
mation technology from Capella University; and multiple certifications,
including CISSP, CISA, NSA IAM and MCSE.




Security at the Speed of Innovation
Remember when transferring money from one account to another meant a trip to your friendly
local teller? Now, almost every aspect of our lives, from financial to gaming to workflow man-
agement to social, is controllable from a mobile device with only a few taps. A game written by
a 14-year-old can get millions of downloads in days. As a business, if you haven’t responded to
this instant-gratification reality by releasing a dedicated, feature-rich application for your cus-
tomers, you’re already behind your competition.

But the dark side to this rush to release new shiny applications for Android, Apple, Blackberry
and Windows Mobile devices is that security—of consumer data, applications and our infra-
structures—is sometimes an afterthought. Our May InformationWeek Analytics OS Wars Survey
shows double-digit adoption of not just Windows but Android, Apple OS X, open-source and
vendor-specific Linux, RIM BlackBerry and Unix. None rated less than 28% usage among our

Figure 1

IT-Supported OS Platforms
Which of the following OS platforms are officially supported by IT and running in production within
your organization on any device (including servers, desktops, laptops, mobile devices, terminals, etc.)?

Windows
99%
RIM (BlackBerry)
52%
Apple/Mac
50%
Unix
37%
Linux (open source)
35%
Linux (vendor-specific)
34%
Android
28%
Note: Multiple responses allowed
Data: InformationWeek Analytics OS Wars Survey of 441 business technology professionals, May 2011
R2890711/1




441 respondents. Their top concern over the growing number of devices and operating systems
that they need to support? Security, cited by 62%.

That’s a lot of platforms, all needing apps, and developers are only too happy to oblige.

Now, there’s a concept that circulates in the security community every few years, coming back
to life as each new batch of researchers fails to read the archives of those who came before
them. The idea states that the more code written, or running on a platform, the more vulnera-
bilities will be present; we assume all applications have as-yet-unidentified security flaws. If you
follow this theory and accept that applications written to run on mobile devices are no excep-
tion—and we do—then it follows that, with each application we develop, we increase the risk
to our organizations, employees and customers.

Your developers are human, and humans make mistakes. All code has security defects, evi-
denced by the bugs discovered after each application vulnerability assessment. And as mobile
platforms evolve and the functionality of the applications running on them expands, so do the
associated risks. An application that can be exploited may be the gateway needed to access data
stored on the mobile device or by the application remotely, or to take control of the device and
tunnel into the network. So far, we’ve seen little action in this area, but we need only look at
how devices that were once closed ecosystems, like gaming consoles, evolved and thus opened
more attack vectors to get a glimpse of our future if we don’t get serious about writing secure
mobile apps.

Faster Isn’t Always Better
Politically, the biggest challenge is often reining in free-spirited developers intent on pushing
out code as fast as they can. This is a hyper-competitive market, and the business very likely
has little patience for slowing down releases because of secure coding practices.

Since we never want to be blamed for late releases, we must implement security without
impacting timelines. The obvious way to manage this feat, and something most of the industry
has learned from Web application security, is to make sure everyone in the project knows what
needs to occur, communicate timelines and see that those timelines are reflected in the project
schedule. Sounds easy enough; it’s getting to this point that’s hard.




First, we must determine how to meet security requirements in the lowest-impact way. Using
automated code analysis software during the build/test process, performing some security test-
ing during the QA process and working with developers to use standard preapproved libraries
that have been reviewed for security go a long way toward reducing the effort required during
the final security review process, which typically occurs at the end of the development timeline
and leaves little time for security testing and remediation.

Beyond these steps, remind the business of the many downsides of releasing a product, inter-
Figure 2

Top Concerns With Growing Number of Devices and Operating Systems
What are your top concerns over the growing number of devices
and operating systems that you may need to support?

Security risks
62%
Too many varieties of devices and operating systems to manage
53%
End user support
43%
Lack of a centralized platform to manage them all
39%
Cost of maintenance
23%
Cost of management
21%
Loss of control over process
20%
Differing authentication methods
8%
Rising costs of devices
6%
Other
2%
Note: Three responses allowed
Base: 343 respondents concerned about supporting a growing number of devices and operating systems
R2890711/7




nally or externally, before it’s ready. Best case, unstable applications reflect poorly on your com-
pany and have to be corrected with updates. Worst case, they lead to data compromises and
you end up in the middle of a PR nightmare.

Where the Risks Are
Since mobile applications typically connect to Web apps to send, retrieve and process data,
some of the largest risk is at the Web application layer. If you’re already performing code
reviews, using standardized libraries and applying other application development processes to
protect Web applications, you’ve done a lot of the work needed to secure mobile applications.

If your organization hasn’t tackled Web application security or has traditionally developed only
client, server or back-end applications, you have some catching up to do. Get your developers
and security team up to speed on SQL injection, session hijacking, insecure authentication and
cross-site scripting. The good news is, the industry at large has been dealing with these issues
for a number of years, so there is less disagreement on how to remediate, documentation is
better than it used to be and it’s easy to find knowledgeable people to assist. To start, read
OWASP’s Top 10 Web application vulnerabilities.

Expanding secure development guidelines to cover mobile apps requires that you review your
standards, tools and processes and work with your development teams to ensure these fit with
how mobile applications are being built, tested and released. Some organizations are outsourc-
ing all their mobile application development; this does not absolve internal development staff
of making sure these apps are secure.

For mobile applications calling a Web application, the design flaw that has bitten several com-
panies is transport security. When sending data back and forth, don’t assume the connection is
encrypted or that, since the mobile platform is closed, the data is safe. Many have fallen victim
to this flawed logic and been proven wrong. Always encrypt customer or other sensitive data in
transport. If there is no reason not to, go ahead and encrypt all transfers, all the time. Gone are
the days of expensive SSL processing, offloading and termination, so that age-old excuse is no
longer valid. If you always encrypt data in transit, that’s one less thing to worry about.

You may ask, if there’s no reason not to encrypt in transit, especially if the mobile application
connects to a Web service, why doesn’t everyone already do it?




In our opinion, there is almost no excuse. If your application is connecting to a third-party
application or a non-Web application, then encryption may not be possible, and the organiza-
tion must weigh the risk to the data being transmitted. One common mistake developers and
product managers make is to assume that users will always use encrypted Wi-Fi connections,
or that the mobile operations network is secure. Both assumptions are incorrect. And, in our
experience, developers often simply forget to use HTTPS. Maybe they’re uneducated on the
risks or used HTTP in development to troubleshoot and never switched to HTTPS before
release. Testing to ensure the application utilizes HTTPS is straightforward and can be per-
formed by QA staff.

Ensure development and review standards applicable to the Web application supporting your
mobile applications, or equivalent if your application connects to another type of system,
encompass components developed specifically for the mobile functionality. This is a great way
to ensure mobile application interaction is being paid the proper attention.

After ensuring data transport, mobile-centric and infrastructure security are addressed, analyze
the risks particular to your application, focusing on what you can control. Understand how this
application may interact with third parties, accept input or provide output to the user.

In most cases, data storage is the next highest risk area, in terms of the user, that you can con-
trol. If the application stores data, consider how and where. Is the storage on the mobile device
secure? Is the data is copied securely when the device is backed up?

“Many of the applications today have absolutely no need for persistent data storage,” says Raf
Los, a security solutions specialist with HP. “In an increasingly connected world, the mobile ter-
minal should simply act as a view into the data and never store anything sensitive long-term.
Storing sensitive information on a mobile client, no matter how secure you think you’ve made
it, is asking for trouble.”

Los says there are four keys to success in securing mobile apps—process, education, automa-
tion and governance—and advocates a program approach that entails gaining an end-to-end
view of the processes involved in addressing threats, ensuring continued improvement in appli-
cation quality and remediating issues as they occur. This method is more effective than
attempting to resolve application security issues in silos or on a one-off basis.




Platform Peril
As we move from the application UI to lower-level operations, understand that your options
will be limited and vary greatly from device to device. Each platform has its own set of APIs
and capabilities that it extends to the application layer. Some, like Android-based devices,
allow application developers a lot of freedom, while others, such as Apple’s iPhone, try to
tightly control what a developer can do.

There is much argument about whether or not platform manufacturers should tightly restrict
developer, and user, accessibility to the underlying operating environment and interaction with
other applications. Some security professionals feel tighter controls reduce the likelihood of
successful attacks and point to the number of malware-infected and malicious applications
found in the Android marketplace. Others believe a lack of accessibility inhibits innovation and
that the real threat is not a malicious application or a pirated version of Angry Birds wrapped
in malware, but the security of the underlying operating environment.

Figure 3

Active Monitoring of Remote PC and Mobile Device Access
Do you actively monitor remote PC and mobile device access by personal devices?

Yes; advanced including antivirus
updates and/or patch management
18%
Yes; basic security
45% and status monitoring

37%
No

Base: 335 respondents at organizations allowing employees to access company resources via personally owned
computers or mobile devices
R2890711/19




Both have valid points, but our take is that it’s hard to ignore the number of malicious applica-
tions appearing and compromising data.

Storage on mobile devices will be a critical area to address as platforms become more open and
users begin to save more personal data locally for anytime, anywhere and offline access.
Currently, most mobile applications save login information and some preferences and might
import data from the device or a remote Web application. All of this data needs to be protect-
ed, but your current development methodologies may not do the job since developers have lit-
tle control over how data is stored and protected. Review what options are available on the
platforms you support, and determine what can be saved locally, how and for how long. For
example, Wells Fargo’s mobile application for the Android platform was found to store user
passwords insecurely, placing bank accounts at risk via malware-infected devices.

Beyond knowing what our apps are storing on a given platform, we must understand where
data is stored, if it’s encrypted, length of time it’s kept and any applicable policies. If your
application is storing passwords, banking data, healthcare information or anything else that
could be valuable to an attacker, again, it needs to be encrypted when in transit and at rest.
The same rules apply here as developing any application: If the best practice is to encrypt, do
so. Don’t rely on the device to be secure or think it will protect data because it’s a closed
ecosystem. You never know what change may occur on the platform that could leave you
exposed. Look at it this way: You lock your apartment door, even though the main building
front door is access-controlled and trusted people live there. It’s a closed system—until one
malicious person moves in and pokes around to see what he can steal. Mobile platforms are the
same way. We treat them as these controlled environments, but as soon as one malicious app is
loaded, there goes the neighborhood. So always protect what is yours.

E-discovery, data retention laws and the sensitivity of the data in question all play roles in
application security. Closely related is data residency. If your application may allow access to
the personally identifiable information (PII) of a citizen in one state or country by a citizen in
another state or country, does that affect the compliance of your organization or any of the par-
ties utilizing your application? Any time an organization is developing an application that will
access data it stores, specifically PII, for use by a distributed workforce or third-party partners,
a privacy and data compliance review must be completed to ensure there are no violations.
Consider caching as well as permanent storage.




Adapt and Adjust
Once you have a grasp of the gap between what you could once control and now can’t, it will
be will be easier to understand what, if any, new risks mobile applications pose to your organi-
zation and customers. Similarities will also begin to emerge. From this point, you can begin to
review your SDLC and align standard practices and controls put in place for other applications
with new development projects. Proper input validation and filtering of data are still relevant
on mobile applications, for example. If bad data is accepted that can be used to exploit the
application and take control of the device or remote service, then there is a risk. Input and out-
put validation, secure sessions and authentication, and ensuring connections are secure will all
port over.

The methods by which you implement these controls will change since the new platforms will
be new languages, but the principals are the same.

Once mobile application development is aligned with your SDLC, or a new methodology is
Figure 4

Standard Configuration for Personal Mobile Devices
Do you require a standard configuration for personal mobile devices that access the network?

Yes; we have a strictly enforced
set of rules (including OS, antivirus, etc.)
28%

Yes; we have general
42% guidelines, but we don’t
necessarily monitor
or enforce

30%
No; they can use
anything that can connect

Base: 280 respondents at organizations allowing employees to access company resources via personal devices
R2890711/16




developed, you must figure out how to test your applications for security flaws. Since mobile
devices are more closed than other platforms, present new languages, and have toolsets that
haven’t evolved in all areas, this can be more difficult than you’d expect. Thus, it’s even more
important that controls have been defined and vetted for developers. For instance, if a standard
set of functions has already been validated to be secure and approved to be reused as a stan-
dard, then the application security team doesn’t have to re-review it. But the team does need to
ensure those functions have been used properly and that other issues are not introduced
because of the new mobile environment.

The easiest way to start testing is to document what the application does and how it integrates
with Web applications or other devices. Hopefully, this information already exists in the prod-
uct requirements. Perform a threat model exercise to understand where the largest risks live,
and then dive in. If external assets the application communicates with have already been
assessed, that piece is complete.

Testing network transport security is as easy as routing the mobile device through a proxy,
monitoring traffic to ensure it properly protects sensitive transmissions, and looking at data
transferred to and from the application to understand what could put your data at risk.

Selective Review
For years, developers have been told how important code reviews are. Still, the quality and
thoroughness of these reviews varies from organization to organization and even staff member
to staff member. The more lines of code reviewed, the more complete the code assessment. But
when faced with deadlines and diminishing returns, implement a process to ensure that, at
minimum, the highest risk areas of the application, such as those that accept input, perform
authentication and manage data storage, are reviewed.

Also remember that with each new mobile platform for which applications are built, your
developers may be adding a new programming language as well—one your source code audit-
ing tools and staff may not understand.

“Currently there is a lack of tools that developers can use to perform source-level analysis of
Objective-C code,” says Vincent Liu of consulting firm Stach & Liu.




If you currently use a source-code auditing product, ask the vendor if and when it will support
the additional languages you require. In the meantime, if you’re faced with an application in an
unfamiliar language that needs review, you could hire a third-party vendor to perform the
assessment. If that’s too costly, at minimum, have a different developer from the one who origi-
nally wrote the app sit with the developer and walk through the code. Ahead of time, the secu-
rity team should threat-model the application with the developers and highlight the areas of
code to focus on.

After a peer review, the application security staff should then walk through sections of code
with the developer, explaining what they’re looking for and validating security. This is obvious-
ly not the most efficient way of doing things, but if you have an application that touches high-
risk data, it is a valid review process and can net results.

As new business opportunities emerge, so too will new risks to our organizations and cus-
tomers. Our job as security experts is to develop strategies to execute these new opportunities
while protecting the valuable resources we’re entrusted with.

Mobile application risks aren’t new. The security challenges presented by these applications
aren’t new. These problems have been solved several times over with client-side and Web appli-
cation security strategies. Just like any new platform or programming language, you will be
faced with fresh operational problems for testing, automation and language support. But these
will be overcome in time as vendors catch up and get tools out to help us perform these tasks
more efficiently.

Until then, keep security in the conversation, because Angry Birds are nothing compared with
Irate Customers.




Want More Like This?
Making the right technology choices is a challenge for IT teams everywhere. Whether
it’s sorting through vendor claims, justifying new projects or implementing new sys-
tems, there’s no substitute for experience. And that’s what InformationWeek Analytics
provides—analysis and advice from IT professionals. Our subscription-based site
houses more than 900 reports and briefs, and more than 100 new reports are slated
for release in 2011. InformationWeek Analytics members have access to:

Research: Hardening Web Applications: Application security is a hot topic today. It was
a hot topic last month, and we believe it will stay a hot topic well into the future. We
examine some of the new pitfalls organizations need to avoid and explore changes in
the security landscape.

Informed CIO: Mobile Device Security: Smartphones have already altered the enterprise
risk landscape, and tablets will only accelerate the pace of change. Employees want
access from their personal devices, and companies need to provide it. Given these
trends, we offer four strategies for reducing the risk that mobile devices create for
enterprise data.

Informed CIO: Beating Security Data Overload: By the seat of the pants is no way to pri-
oritize security spending and set project precedence. But we found that’s exactly how
some CISOs are doing business. This must change, and we’ll tell you why (and how).

IT Pro Ranking: Web Security Gateways: IT pros give high marks to makers of Web
security gateways for their ability to block malware. But when it comes to manage-
ment, there’s room for improvement.

Strategy: Malware War: The stakes have never been higher in the fight for control of
corporate and consumer devices, as security labs work ’round the clock to analyze
malicious code and the bad guys design ingenious new ways to one-up them.

PLUS: Signature reports, such as the InformationWeek Salary Survey, InformationWeek
500 and the annual State of Security report; full issues; and much more.

For more information on our subscription plans, please CLICK HERE.


The Darkside of Mobile Applications

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The Darkside of Mobile Applications

Similar to The Darkside of Mobile Applications (20)

More from Wirehead Technology

More from Wirehead Technology (20)

Recently uploaded

Recently uploaded (20)

The Darkside of Mobile Applications