Enterprise mobility and Android

Its quite some time after the GoogleIO. Have been busy digesting some info and thinking a lot. Just a day before IO, I wrote some of my thoughts on Enterprise mobility. Today, I'll try and visit certain aspects in detail as well as try to list what Android has to offer as of now.

Now, from current trends in market and from my understanding till date, I see the current enterprise mobility having 3 components as follows :

1. Device Management
2. Security
3. Application management

Enterprises looking for a complete mobility solution are mostly looking at these three areas. I'll try to briefly touch on each of these and discuss what Android has to offer (and not offer) to enterprise mobility. [For clear separation, I have marked Android Specific details in BLUE : I know Green (#A4C639) would have been appropriate, but I didn't think it was good for reading :)]

1. Device Management :  Device management (DM) mainly deals with being able to remotely alter certain aspects of the devices. Again, I see DM being split into the following.



i. Provisioning deals with mass deployment of various settings on large number of handsets.  For instance, provisioning the devices with corporate WiFi information, VPN access parameters and configuration of email settings etc... For the IT department, being able to provision these settings is beneficial since it helps them carry out the tedious task as well as reduces chances of human error and avoid complex email instructions.

Blackberry and iOS have most of the DM functions baked into the platform. This means, one can configure a DM server (may require manual steps). Once configured, the DM server can send commands to the device which will be understood by the device platform and reacted accordingly.

Android, however, requires an on-device management agent (aka Device administrator) which should implement the Device Admin APIs (Android 2.2 onwards) in order to perform any of the DM functions. Furthermore,  Android doesn't support provisioning out of the box. Rather of all the top IT demands (WiFi, VPN, Exchange etc...), only WiFi can be configured programmatically by the on-device agent.

ii. Device Control deals with being able to remotely take certain actions on the device that may affect the end user. E.g. device lock, unlock, wipe, set/reset password.

With the device admin software installed, Android can do these basic device control functions like device wipe, lock/unlock and set/reset password.
There is however one way to achieve device control functions without having to install any device admin. The trick here is that most Android devices ship with a Email application which can be configured with Exchange information. By default Exchange uses the ActiveSync protocol for syncing mails. Of lately (I guess Android 2.2 onwards), I have seen that while configuring Exchange, the platform shows the standard Device Management screen asking for adding the Exchange as a device admin. If you do this, then by configuring the Email, you can execute device control commands like lock/unlock, set/reset password, wipe etc... To check this go to Settings -> Location and Security -> Select Device administrators. You should be able to see Email application being listed if you have configured Exchange (ActiveSync ).

iii. Device Policies : Policies allow enterprises to control certain settings of the device. This is different from provisioning in that policies can be considered as 'enforced' settings. While someone may change the provisioned settings, device policies are not "meant" to be changed. On Blackberry and to some extent the iOS, the platform restricts the user from changing any policies set by the IT administrator. These policies may include restrictions on the browser to disable javascript, avoid using the phone as USB storage device, disabling camera, etc...

Again, in the case of Android, you will need the on-device admin app to control (only) a subset of what the IT demands traditionally. Basic policies like enforcing a device password, password quality etc.. are supported out of the box with the Device admin APIs.

2. Security : By far, this is THE feature enterprises cannot live without. When enterprises allow data to be accessed remotely, its security is of prime importance. There are 3 components related to security that I visualize as follows:



i. Encryption : Any data that is stored by any application as well as any data that is communicated to and from the device, needs to be encrypted.

Android apps can use SSL tunnels through with data can be transported. However, the data stored on the device (phone memory and SD) is up to the applications. Prior to honeycomb (Android 3.0) there is no support for turning on encryption on the device. Even with Honeycomb, a device administrator application can request for the encryption process to begin, and it will start the encryption ONLY IF it is supported by the device on which the agent is running. Things are still pretty unclear about the way encryption is supported (hardware vs software etc...). One of my previous posts raises these issues. I'll update both the blog posts once enough information is available.

ii. Device Policies : I have purposefully included policies again under Security. I think this link is important to note. This is just to remind that policies are restrictive settings enforced in order to avoid security compromise.

iii. Compliance : Now, we have policies in place. And as I said these need to be enforced on the device. However, it may happen that the user knowingly or unknowingly changes some setting that violates certain policy (that cannot be technically enforced on the device - technology limitation). This may put corporate data at risk. It is important for the IT to determine such instances. This leads to constantly monitoring the device and making sure that it is "in compliance" with the policies.
Usually, compliance checking may be done on the server that monitors the device. This can be achieved by querying the device for certain parameters periodically and then running the compliance rules against the values received. These rules usually test whether the device adheres to all the policies, if not then the resulting actions could be anything from blocking corporate access for that device to wiping the device. This totally depends on the IT policies for the enterprise.

The device admin app can play the role of reporting parameter values to the DM server. To monitor Android for certain metrics, the server can implement the Google C2DM (cloud to device messaging discussed in this blog post) to send query messages to a device admin app which can reply back. 

3. Application Management : One of the basic goals for enterprises is to mobilize the business. As a result, enterprises have started mobilizing many internal applications. So, as a part of enterprise mobility, the IT also has to manage the mobile apps. Application management (AM) can be again viewed as having the two main functions :



i. Monitor/Debug apps : Since most of the applications may be internal apps, the development and testing phase becomes critical. Also, since these apps may directly affect employee productivity, debugging these apps during development and after deployment is crucial too. One of the tasks of AM is to help the development and debugging process easier. Once the app is in production, AM can help monitor the status of apps and surface any problems earlier. Monitoring of apps may also refer to getting an apps inventory and determining "blacklisted" apps from security point of view. This may tie back to compliance.

ii. Deploy / Remove apps : With many such applications there is a demand for Enterprise application catalog on which apps would be listed and shown/accessed depending on the role of the employee. Since these apps may contain critical corporate information, it is important for the IT to be able to control these apps remotely. Being able to install, remove these apps is one of the most popular demands from IT.

With Android, anyone can "sideload" an application. This means all the application (apk) files can be accessed via a webpage. However, there are few points to note. In order to install any application that is not listed in the Android Market (consumer app), one has to enable a setting called applications from an "Unknown Source". While doing so, the user gets a dreaded message that may scare him off. Also, it is worth noting that there is currently no official way to push the application on the device and install/uninstall it without the user intervention. If you already have your device admin agent on the device, then it can download the app binary and trigger the install process or trigger the uninstall process of an existing app which will redirect the user to the install/uninstall approval screen. There are some app markets (like AppBrian) which have (with limited capabilities) "managed" to remotely push and install applications on Android phones. However, there is no official way to do so.

So, here is a complete picture of how I see Enterprise mobility as of now:




To summarize, Android really doesn't have much to offer at this moment apart from few Device Admin APIs and Encryption (hardware dependent - 3.0 onwards). With the growing demand for Android and the changing trend of Employee liable devices, it certainly is a challenge for IT. The Google enterprise team unfortunately didn't seem to address most of these issues and didn't seem open to a lot of questions posed at the GoogleIO. The talk at GoogleIO can be found here : (http://www.google.com/events/io/2011/sessions/taking-android-to-work.html) I hope they have some plan for the Enterprise mobility because the wave has just begun.

Understanding Enterprise Mobility

[I'm sitting at a Starbucks waiting for the GoogleIO registration to open up. There is an interesting session 'Taking Android to work' which I'll be attending. Google's approach to enterprise mobility seems to be different than Blackberry or Apple : they don't have anything baked into the platform. The GoogleIO session will hopefully provide more insights into the future path. If you are an attendee and interested in this topic, I would definitely love to have a chat with you. You can follow me on Twitter : @advantej ]

For the past few months, I'm trying to understand the enterprise mobility space. It had kind of existed in the past but emerging again with a new face altogether. Its definitely a larger wave than the earlier one.

A look into the past: 
Laptops introduced mobility into enterprise. There were cell phones before, but those weren't 'smart' enough. Their primary purpose was just to carry out conversations. Laptops made it possible to take the work with you. There was also a short period that showcased Personal Digital Assistants (PDAs) which were rather bulky to carry around and capabilities mostly limited to managing your schedule, taking notes and some basic messaging. But the truly workable mobile devices were laptops.

The Enterprise Viewpoints: Two sides of a coin
The Good:
For enterprises, mobility means a lot. It is a means of growing business, capturing opportunities and bringing back information, knowledge, keeping the organization going on, no matter where the people in the organization are. Be it the CEO, CTO, marketing or sales people or any other management folks or your awesome engineers: mobility builds the necessary bridges whenever it matters to achieve the required goals.

The Worrisome:
However, practically this means accessing company resources from devices and environments on which enterprises may not have any control. While mobility helps enterprises grow the concern about information security in uncontrolled environments makes enterprises take a step back.

In the laptop/PDA wave, managing devices was pretty much conventional. There was nothing new to do at least for the laptops because they had to deal with the same operating systems on laptops for which IT management was already being used for a long time.

For pretty much long time, RIM provided enterprises with a solution to control the Blackberry mobile devices, enabling them to configure, manage and enforce policies on the devices.

With Apple and Android powered devices entering the consumer market with different form factors, mobility has a new face. Not just that there are a lot of devices from different vendors and operating systems, its the fact that employees are consumers first. They are pretty much demanding the use of devices of their choice for accessing enterprise resources. Moreover, people don't like to carry multiple devices : a personal device and a company owned device. They want it there - all in one.

The challenge for the IT is to support multiple mobile devices ensuring safety and security of enterprise resources. Apart from security which is central to enterprise mobility, IT demands being able to configure devices no matter what OS its running.

Being a newbie to this space, I think of a lot of questions that I'm trying to answer. With many enterprise applications emerging, is enterprise mobility management limited to managing just the devices ? What about the applications ? Do we need to control and analyse those too ? With employee owned devices is it acceptable to enforce enterprise policies all the time ? Some policies require control over the hardware as well. In my masters thesis, I explored context awareness frameworks for mobile devices and prototyped one. I was wondering if it makes sense to exploit user context for enterprise policies. This may help in selectively applying policies depending on user context. This may help develop a win-win situation where employees don't feel controlled all the time but would be able to access the required resources. (For curious reader : here is an interesting academic research project trying to identify high level contextual aspects for a mobile user.)

Have got these questions and many more.... but one thing for sure - this wave is very large, unavoidable, with a lot of challenges and comes with competitive problems for the architects and engineers to solve.


[Thank you Starbucks for the internet !]

Android 3.0 encryption : Initial Thoughts

A little background:

Few days back Google released a preview version for the Android 3.0 SDK code named HoneyComb. For quite some time now, the enterprise has been asking for device management features for the Android Platform. Blackberry has these features integrated into their solution. Recently Apple also embraced the initiative and supported enterprise features in their iOS 4.

The obvious reason for these trends is due to the customer demands. Earlier, enterprises used to provide employees with smart phones (read blackberries) to access corporate resources. Blackberry was the only solution providing secure corporate access, encryption and security policies. However, with iPhone getting popular, the momentum shifted in last couple of years. Now, instead companies providing the smartphones, employees demand the type of phone they want and companies' IT departments have the daunting task to support these smartphones. These demands lead Apple to add device management support to iOS.

Android seems to be a very different game. It is gaining a lot of popularity these days. The open nature of it has enabled the platform to be adopted by a huge number of manufactures resulting in a burst of Android powered devices. In the corporate world, employees are asking for supporting Android devices too.

Some initial thoughts (technical):

In Froyo (Android 2.2), google introduced some device admin APIs. Using these, some basic device management functionalities could be achieved. (Device lock, set password, device wipe). However, one primary concern for corporates is Encryption !

Just few days back, google released a preview version of honeycomb SDK. This is my interpretation of the Encryption API found in HoneyComb preview SDK. I'll update the blog or write a new post when I learn more on this.

As a device admin, an application first has to check weather Encryption is supported by the tablet (in hardware). I don't think there is software encryption algorithm in honeycomb. I'll be surprised to see a software encryption (it will defenitely slow down the tablet in my opinion - but who knows, there are always surprises in the world !).

So, assuming there is hardware support, the admin app can test it (using the getStorageEncryptionStatus) and then call the start encryption method (setStorageEncryption). This will trigger the hardware encryption process. According the honeycomb preview api documentation, this will encrypt only the application storage area (i.e. all the internal memory - my guess) and may not the external memory (sd card).

SDK documentation for the setStorageEncryption says:

<snip>
This policy controls encryption of the secure (application data) storage area. Data written to other areas (e.g. the directory returned by getExternalStorageDirectory() may or may not be encrypted.
</snip>

I came across an engaget article that says that the motorola xoom has an option to encrypt the entire tablet. This is a bit incomplete and misleading. Does this mean that Motorola has extended honeycomb to encrypt the SD card as well ? Who knows, only time will tell. I'm curious to know what kind of encryption is supported - hardware/software. Will it (and how much) affect the performance ? and will this initiative please corporates and will they embrace Android devices ?

Time will tell and if it tells me first, I'll update the blog :) Do leave any comments if you find any information or corrections.