One of the most frequent questions I hear in inquiry calls with our enterprise clients at the moment is “how do we manage and secure iPads on our corporate network?”
Not “tablets” (at least, not yet), but “iPads” specifically.
Whereas the smartphone began the push for consumerization and “bring your own device” (BYOD) in the enterprise, the iPad has consolidated that move. The dynamic has changed because the iPad appeals equally to senior executives and mere mortals, and the IT department finds it much harder to push back when the CEO demands his corporate email on his new iPad. Secure board communications systems (BCS) are also something of a hot topic right now, and the iPad is making a significant impact in that market too, offering, as it does, an attractive alternative to lugging around giant paper-based folders of corporate documents.
With the release of iOS4, Apple introduced a number of features that finally allowed IT departments to consider the iPhone and iPad as “enterprise ready.” Mobile Device Management (MDM) APIs and Data Protection capabilities provided the means for enterprises to manage and secure both the devices themselves and the data stored on them.
Questions remain as how best to secure both device and data, and forthcoming research from NSS Labs on Data Protection and MDM will provide actionable advice to assist our enterprise clients in deploying these devices in corporate networks.
iOS4 still fell short in a couple of key areas when it came to enterprise deployment, however. The lack of secure email support and reliance on iTunes – a consumer-grade software product - for critical processes such as device activation and backup were two major concerns.
As expected, both of these will be addressed in the latest iOS5 release, though it remains to be seen how welcoming enterprise customers will be about certain aspects of Apple’s new baby. Having installed iOS5 on a few devices, I can say that it appears very solid so far for a beta product, though it is still missing some features that were promised in the WWDC keynote.
S/MIME support addresses the secure email concern adequately, and it appears to work well. I tested using both standard commercial and self-signed certificates, and digital signing and encryption functions worked fine for sending and reading messages. Certificates are installed via configuration profiles using the iPhone Configuration Utility (IPCU), following which they need to be selected for signing, encryption or both on a per-mail account basis. This process will need to be streamlined in larger deployments by the use of third-party MDM solutions in order to scale. Grabbing certificates from messages sent to you to store in the address book is a simple, one-click process.
The objection to iTunes has been addressed by the new “PC free” capabilities in iOS5. Apple explained at its developer conference that the aim was to add sufficient features on the device to remove the requirement for users to tether to their desktop. At the consumer end of things this includes features such as on-device photo editing, calendar creation and mailbox creation. For the enterprise, the killer blow comes with on-device activation and over the air (OTA) operating system updates, eliminating the requirement for iTunes in deploying iOS devices. Delta updates are also possible now, meaning that it will no longer be necessary to download the whole OS each time Apple issues a change. Backups will be achieved via the new iCloud service, and it remains to be seen how secure and acceptable this proves to be for enterprises (at this point in time I am unable to test all of the iCloud features.)
So nothing earth shattering, but a steady evolution of the system to make it ever more acceptable to enterprise customers. Apple could, and should, have gone further, however.
Multiple email signatures with per-account defaults is a feature to which users are accustomed on their desktop mail clients. This is still missing from iOS and, while not a major problem, is something I find irksome on a daily basis as a business user.
More serious is the continued omission of support for the iOS Data Protection APIs by Apple’s own “business” apps – Pages, Keynote and Numbers. Apple announced Data Protection with a fanfare with the release of iOS4 and informed us that, although Mail was the only native app to support those APIs back then, others would quickly follow. That appears to be an empty promise, since I am not aware of any other apps in the Apple stable that support the encryption APIs today.
This capability becomes even more important with the announcement of the multi-device synchronization capabilities of iCloud, which could easily see confidential documents created on a Mac desktop pushed out automatically and invisibly to iPhones and iPads, where they will rest unprotected.
Finally, we still do not have the ability to prohibit the creation and use of the escrow keybag when synchronizing to iTunes. This would be a simple feature to implement, and would provide an additional layer of protection for those relying on Data Protection capabilities to protect their data on mobile iOS devices. One other option would be to force permanent “PC free” mode, prohibiting iTunes synchronization at all, though that would require apps to support iCloud natively for file transfer, and is not something we are likely to see in the immediate future.
I have an Analysis Brief in production right now for our subscribers that will address the Data Protection capabilities in iOS4 and iOS5, and how they should be used to protect sensitive corporate data. Follow me on Twitter (@bwalder) to keep informed as new research is released.
[UPDATE]: Some have reported issues with S/MIME in iOS5, and the beta implementation does certainly seem to be a little "quirky" at the moment. I found issues when using certificates issued by public CAs such as Verisign, which I circumvented by installing self-signed certificates that I created using OpenSSL. Naturally, this does not play well in the world outside your test environment, but if you are just looking to test functionality, I found that both sending and receiving signed and encrypted messages worked fine using this solution.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment