Mobile application security is not limited to device management but must also be built into the application itself. Enterprises are rapidly adapting security guidelines for mobile apps. Things such as password storage, server connection timeout and data leakage are all important security areas to address. While system and data encryption are part of the mobile platform software development kit (SDK), it is still up to the application developer to decide how to secure the data and determine the level of data sharing that is required for any given app. This is an interesting problem for the Android platform, which is built to be open and encourages ease of data sharing. However in an enterprise application, especially one deployed on a personal device, the enterprise data must be securely contained to the app and not shared or leaked to the system or other apps.
The Android intent
An intent is an Android development component that allows data to be shared between applications. Intents allow applications to share data openly without requiring the developer to write integration code or even know what applications are available. It's a broadcast system of sharing and consuming data simply using what's installed. While the “share intent” is a standard data sharing method for Android applications, this poses a security risk for enterprise data. There is no control over what applications are available to consume the data or how the data will be used once it leaves your app. While data sharing using intents is easy and preferred by the Android OS, it is not enterprise or security friendly. For example, say you want to view a document attachment sent to you in your email. Android would easily allow this document to be shared out to QuickOffice for viewing and editing. However, this document might contain confidential data that should not be viewed unsecured using a third-party app. The share intent should not be used by default for enterprise data.
The content provider*
Enterprise data can be shared if all the apps are signed by the same provider and only share data with each other. An enterprise may provide their own mail, calendar or document apps and enable data sharing among them. Android makes this data sharing easy with the use of their content provider application programming interfaces (API). Enterprise developers can create content providers for their specific applications. Applications can write their own providers and provider clients. The interface is called ContentProvider. It allows applications to share data using a well-known protocol. Applications implement the ContentProvider to receive requests and process the data. On the other end, applications implement the ContentResolver to request and access the data. Application data is stored in a repository similar to a relational database. Data is then returned in a table format and can be accessed using a structured query language. The content provider interfaces can be used to create, update or delete data as well.
Content providers must define permissions in order for other applications to access their data. The data consumer app must also include <uses-permission> for each permission defined. In addition to exclusive data sharing among the apps, to ensure secure access, the data access is protected by Android permissions and the apps must be signed by a single enterprise certificate while also enforcing signature-based permission checks. The application should accept data requests made by another app only if they can validate the app certificate signer and the signature security permission. By using the signature protection level, the Android system only grants permission if all apps are signed by the same certificate authority. Android provides a rich set of functionalities to access data across applications in a secure and efficient way that's usable for effective enterprise mobile application development.
Containing the data
Another way to keep the data secure is to not share it. An enterprise would have the resources to build an application that provides integrated functionality within one app and could therefore remove the need for data export or sharing. For example, a file browsing app can have built-in viewing and editing capabilities so the user can securely read and edit the file all within the app. This includes the ability to upload it to a server-side repository and remove the data from the device.
As more enterprises adopt the mobile first approach, they will need to re-architect application data to optimize it for mobile consumption. Developers need to be trained in corporate security policy in order to make the best decisions for what works on mobile. How do you protect your mobile enterprise data? Leave a comment or connect with me on LinkedIn to discuss further.
*Some of the text in the content provider section is borrowed from an article I contributed to: see David Jaramillo, Viney Ugave, Charisse Lu and Rick Alther, “Android OS in the Enterprise,” in Software Developer's Journal, http://sdjournal.org/qt5-how-to-become-a-professional-developer-released/.