The Darkside of Mobile Applications


Published on

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.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Darkside of Mobile Applications

  1. 1. July 2011 $ 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
  2. 2. Dark Side of App StoresA 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 F u n d a m e n t a l s 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, executive editor Lorna Garey at and research managing editor Heather Vallis at Find all of our reports at 2 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  3. 3. Dark Side of App StoresA 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 F u n d a m e n t a l s 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. 3 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  4. 4. Dark Side of App StoresA 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 F u n d a m e n t a l s 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 4 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  5. 5. Dark Side of App StoresA 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 F u n d a m e n t a l s 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. 5 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  6. 6. Dark Side of App StoresA 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 F u n d a m e n t a l s 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 Data: InformationWeek Analytics OS Wars Survey of 441 business technology professionals, May 2011 R2890711/7 6 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  7. 7. Dark Side of App StoresA 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 F u n d a m e n t a l s 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? 7 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  8. 8. Dark Side of App StoresA 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 F u n d a m e n t a l s 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. 8 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  9. 9. Dark Side of App StoresA 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 F u n d a m e n t a l s 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 Data: InformationWeek Analytics OS Wars Survey of 441 business technology professionals, May 2011 R2890711/19 9 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  10. 10. Dark Side of App StoresA 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 F u n d a m e n t a l s 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. 10 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  11. 11. Dark Side of App StoresA 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 F u n d a m e n t a l s 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 Data: InformationWeek Analytics OS Wars Survey of 441 business technology professionals, May 2011 R2890711/16 11 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  12. 12. Dark Side of App StoresA 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 F u n d a m e n t a l s 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. 12 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  13. 13. Dark Side of App StoresA 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 F u n d a m e n t a l s 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. 13 July 2011 © 2011 InformationWeek, Reproduction Prohibited
  14. 14. Dark Side of App StoresA 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 F u n d a m e n t a l s 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. 14 July 2011 © 2011 InformationWeek, Reproduction Prohibited