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.