The Darkside of Mobile Applications

A n a l y t i c s . I n f o r m a t i o n W e e k . c o m

Report ID: S3060711

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

Dark S ide of Mobi le Apps:Keeping Data Safe on the Move

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

J u l y 2 0 1 1$ 9 9

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

7 Where the Risks Are

9 Platform Peril

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

11 Adapt and Adjust

11 Figure 4: Standard Configuration for Personal Mobile Devices

12 Selective Review

14 Related ReportsCONT

ENTS

TA

BL

E

OF

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 [email protected],

executive editor Lorna Garey at [email protected] and research managing editor Heather Vallis

at [email protected]. Find all of our reports at www.analytics.informationweek.com.

Analyt ics . In format ionWeek .com

D a r k S i d e o f A p p S t o r e s

2 July 2011 © 2011 InformationWeek, Reproduction Prohibited





Adam ElyInformationWeek

Analytics


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-

ment group at Walt Disney Co., where he implemented secure

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 InnovationRemember when transferring money from one account to another meant a trip to your friendlylocal 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 bya 14-year-old can get millions of downloads in days. As a business, if you haven’t responded tothis 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, Blackberryand Windows Mobile devices is that security—of consumer data, applications and our infra-structures—is sometimes an afterthought. Our May InformationWeek Analytics OS Wars Surveyshows double-digit adoption of not just Windows but Android, Apple OS X, open-source andvendor-specific Linux, RIM BlackBerry and Unix. None rated less than 28% usage among our

99%

52%

50%

37%

35%

34%

28%Note: Multiple responses allowedData: InformationWeek Analytics OS Wars Survey of 441 business technology professionals, May 2011

Windows

RIM (BlackBerry)

Apple/Mac

Unix

Linux (open source)

Linux (vendor-specific)

Android

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.)?

IT-Supported OS Platforms

R2890711/1

Figure 1





441 respondents. Their top concern over the growing number of devices and operating systemsthat 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 backto life as each new batch of researchers fails to read the archives of those who came beforethem. 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 youfollow 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 riskto 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 mobileplatforms evolve and the functionality of the applications running on them expands, so do theassociated risks. An application that can be exploited may be the gateway needed to access datastored on the mobile device or by the application remotely, or to take control of the device andtunnel into the network. So far, we’ve seen little action in this area, but we need only look athow devices that were once closed ecosystems, like gaming consoles, evolved and thus openedmore attack vectors to get a glimpse of our future if we don’t get serious about writing securemobile apps.

Faster Isn’t Always BetterPolitically, the biggest challenge is often reining in free-spirited developers intent on pushingout code as fast as they can. This is a hyper-competitive market, and the business very likelyhas 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 withoutimpacting timelines. The obvious way to manage this feat, and something most of the industryhas learned from Web application security, is to make sure everyone in the project knows whatneeds to occur, communicate timelines and see that those timelines are reflected in the projectschedule. 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. Usingautomated 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 librariesthat have been reviewed for security go a long way toward reducing the effort required duringthe final security review process, which typically occurs at the end of the development timelineand leaves little time for security testing and remediation.

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

62%

53%

43%

39%

23%

21%

20%

8%

Note: Three responses allowedBase: 343 respondents concerned about supporting a growing number of devices and operating systemsData: InformationWeek Analytics OS Wars Survey of 441 business technology professionals, May 2011

Security risks

Too many varieties of devices and operating systems to manage

End user support

Lack of a centralized platform to manage them all

Cost of maintenance

Cost of management

Loss of control over process

Differing authentication methods

Rising costs of devices

Other

6%

2%

What are your top concerns over the growing number of devices and operating systems that you may need to support?

Top Concerns With Growing Number of Devices and Operating Systems

R2890711/7

Figure 2





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 andyou end up in the middle of a PR nightmare.

Where the Risks AreSince 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 codereviews, using standardized libraries and applying other application development processes toprotect 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 onlyclient, server or back-end applications, you have some catching up to do. Get your developersand security team up to speed on SQL injection, session hijacking, insecure authentication andcross-site scripting. The good news is, the industry at large has been dealing with these issuesfor a number of years, so there is less disagreement on how to remediate, documentation isbetter than it used to be and it’s easy to find knowledgeable people to assist. To start, readOWASP’s Top 10 Web application vulnerabilities.

Expanding secure development guidelines to cover mobile apps requires that you review yourstandards, tools and processes and work with your development teams to ensure these fit withhow mobile applications are being built, tested and released. Some organizations are outsourc-ing all their mobile application development; this does not absolve internal development staffof 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 isencrypted or that, since the mobile platform is closed, the data is safe. Many have fallen victimto this flawed logic and been proven wrong. Always encrypt customer or other sensitive data intransport. If there is no reason not to, go ahead and encrypt all transfers, all the time. Gone arethe days of expensive SSL processing, offloading and termination, so that age-old excuse is nolonger 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 applicationconnects to a Web service, why doesn’t everyone already do it?

https://www.owasp.org/index.php/OWASP_Top_Ten_Project





In our opinion, there is almost no excuse. If your application is connecting to a third-partyapplication 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 andproduct 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 ourexperience, developers often simply forget to use HTTPS. Maybe they’re uneducated on therisks or used HTTP in development to troubleshoot and never switched to HTTPS beforerelease. 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 yourmobile applications, or equivalent if your application connects to another type of system,encompass components developed specifically for the mobile functionality. This is a great wayto ensure mobile application interaction is being paid the proper attention.

After ensuring data transport, mobile-centric and infrastructure security are addressed, analyzethe risks particular to your application, focusing on what you can control. Understand how thisapplication 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 devicesecure? 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 RafLos, 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 madeit, 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-endview 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 thanattempting to resolve application security issues in silos or on a one-off basis.





Platform PerilAs we move from the application UI to lower-level operations, understand that your optionswill be limited and vary greatly from device to device. Each platform has its own set of APIsand 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 totightly control what a developer can do.

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

Base: 335 respondents at organizations allowing employees to access company resources via personally owned computers or mobile devicesData: InformationWeek Analytics OS Wars Survey of 441 business technology professionals, May 2011

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

Yes; advanced including antivirusupdates and/or patch management

No

18%

37%

45%Yes; basic security and status monitoring

R2890711/19

Figure 3





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 andusers begin to save more personal data locally for anytime, anywhere and offline access.Currently, most mobile applications save login information and some preferences and mightimport 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 theplatforms you support, and determine what can be saved locally, how and for how long. Forexample, Wells Fargo’s mobile application for the Android platform was found to store userpasswords insecurely, placing bank accounts at risk via malware-infected devices.

Beyond knowing what our apps are storing on a given platform, we must understand wheredata is stored, if it’s encrypted, length of time it’s kept and any applicable policies. If yourapplication is storing passwords, banking data, healthcare information or anything else thatcould 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, doso. Don’t rely on the device to be secure or think it will protect data because it’s a closedecosystem. You never know what change may occur on the platform that could leave youexposed. Look at it this way: You lock your apartment door, even though the main buildingfront door is access-controlled and trusted people live there. It’s a closed system—until onemalicious person moves in and pokes around to see what he can steal. Mobile platforms are thesame way. We treat them as these controlled environments, but as soon as one malicious app isloaded, 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 inapplication security. Closely related is data residency. If your application may allow access tothe personally identifiable information (PII) of a citizen in one state or country by a citizen inanother 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 willaccess 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 AdjustOnce you have a grasp of the gap between what you could once control and now can’t, it willbe 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 toreview your SDLC and align standard practices and controls put in place for other applicationswith new development projects. Proper input validation and filtering of data are still relevanton mobile applications, for example. If bad data is accepted that can be used to exploit theapplication 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 allport over.

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

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

Base: 280 respondents at organizations allowing employees to access company resources via personal devicesData: InformationWeek Analytics OS Wars Survey of 441 business technology professionals, May 2011

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

Yes; we have a strictly enforcedset of rules (including OS, antivirus, etc.)

No; they can useanything that can connect

28%

30%

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

R2890711/16

Figure 4





developed, you must figure out how to test your applications for security flaws. Since mobiledevices are more closed than other platforms, present new languages, and have toolsets thathaven’t evolved in all areas, this can be more difficult than you’d expect. Thus, it’s even moreimportant that controls have been defined and vetted for developers. For instance, if a standardset 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 toensure those functions have been used properly and that other issues are not introducedbecause of the new mobile environment.

The easiest way to start testing is to document what the application does and how it integrateswith 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 beenassessed, 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 datatransferred to and from the application to understand what could put your data at risk.

Selective ReviewFor years, developers have been told how important code reviews are. Still, the quality andthoroughness of these reviews varies from organization to organization and even staff memberto staff member. The more lines of code reviewed, the more complete the code assessment. Butwhen faced with deadlines and diminishing returns, implement a process to ensure that, atminimum, the highest risk areas of the application, such as those that accept input, performauthentication and manage data storage, are reviewed.

Also remember that with each new mobile platform for which applications are built, yourdevelopers 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 ofObjective-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 supportthe additional languages you require. In the meantime, if you’re faced with an application in anunfamiliar language that needs review, you could hire a third-party vendor to perform theassessment. 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 ofcode to focus on.

After a peer review, the application security staff should then walk through sections of codewith 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 opportunitieswhile protecting the valuable resources we’re entrusted with.

Mobile application risks aren’t new. The security challenges presented by these applicationsaren’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 befaced with fresh operational problems for testing, automation and language support. But thesewill be overcome in time as vendors catch up and get tools out to help us perform these tasksmore efficiently.

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





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

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

Informed CIO: Mobile Device Security: Smartphones have already altered the enterpriserisk landscape, and tablets will only accelerate the pace of change. Employees wantaccess from their personal devices, and companies need to provide it. Given thesetrends, we offer four strategies for reducing the risk that mobile devices create forenterprise 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 howsome 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 Websecurity 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 ofcorporate and consumer devices, as security labs work ’round the clock to analyzemalicious code and the bad guys design ingenious new ways to one-up them.

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

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

http://analytics.informationweek.com/user/index/regsteptwo

http://analytics.informationweek.com/abstract/21/3675/Security/research-hardening-web-applications.html

http://analytics.informationweek.com/abstract/21/5215/Security/informed-cio-mobile-device-security.html

http://analytics.informationweek.com/abstract/21/5155/Security/informed-cio-beating-security-data-overload.html

http://analytics.informationweek.com/abstract/21/7054/Security/it-pro-ranking-web-security-gateways.html

http://analytics.informationweek.com/abstract/21/5854/Security/strategy-malware-war.html

Technology

The Darkside of Mobile Applications