The proliferation of mobile devices—smartphones, tablets, convertibles, and more—is leading to a fundamental shift in how technology is used both for individuals and businesses. It's also leading to major problems for ensuring mobile security, especially inside of apps. App data is managed through Internet-connected, platform-specific programs for mobile devices, delivered through trusted app repositories. This model has tremendous advantages for consistency and mobility, but it also presents unique problems, many of which are not well communicated by device manufacturers, mobile OS developers, and application developers themselves. Mobile security isn't necessarily breaking news; yet still, enterprises and users keep getting stung by in-app threats to app data. Scott Alexander-Brown's presentation at RSA Conference in San Francisco this year, "Assume a Hostile Environment: Securing Mobile Data in the App" be provided a detailed overview of the threats to in-app mobile data and how to better protect it.

What kind of problems are we talking about? Well, perhaps the biggest is simply fragmentation. With multiple operating systems—iOS, Android, Symbian, and Windows Mobile, to name only a few—vying for supremacy, developers target multiple builds of their applications, all of which may require different languages (Objective-C, C#, and Java) that each introduce unique security issues. All of this can result in potential issues for data security, as one version of an app is relatively secure, while another version that may look and feel exactly the same suffers from data-leaking vulnerabilities. Of course, OS fragmentation isn't the only issue that drags on in-app data security. Another issue is the fact that mobile devices have several interfaces for data transmission: a mobile device can simultaneously be connected to WiFi networks, cellular networks, and Bluetooth networks, all of which are potential vectors for attack and—in the case of apps which are already infected or exploited—multiple paths of egressing private data to people who shouldn't have it. Finally, mobile devices tend to have very non-granular access control. Apps can simply request access to interfaces and APIs, and users can just click a button to grant access. This is a big problem, because often the context of these requests are not clearly identified to users, and the lack of granularity of access means that apps often request—and get—more than they need to function.

Of course, a lot of people will point to app stores as a panacea to the problem: if an app vendor properly vets and certifies developers and goes the extra step of conducting code security assessments on apps before they're available to users, then the problem of insecure in-app data (at least, from the perspective of malware) is moot, right? Not exactly. One problem is ad-based malware. Countless "free" apps out there are supported through advertisement revenue, and attackers know that. A lot of their efforts are spent on this relatively low-cost attack vector, which automatically gives them direct access to users, no malware required. Users then visit links embedded in ads that point to compromised sites. And for people who have jailbroken their mobile devices, intentionally moving beyond "approved" apps to grey-market repositories such as Cydia can give them direct access to malware-infected apps that can compromise data.

Solving the problem of in-app data security isn't easy. The stakeholders in the best position to effect change are the OS and app developers themselves. By sandboxing private data on a per-app basis, encrypting sensitive data in-memory, and providing more granular requests (and access) to application programming interfaces (APIs), OS vendors and app developers can provide a good starting point for shoring-up in-app data security for enterprises and their users. Those constituents also have responsibilities for improving in-app data security, through better security awareness training (on the part of enterprises) and consciously thinking about the ramifications of their actions (on the part of users).