Infoworld deep dive - Mobile Security

1. MOBILE
SECURITYTTYTY
iOS
VS.
ANDROID
VS.
BLACKBERRY
VS.
WINDOWS
PHONE
DeepDive
Copyright©2015InfoWorldMediaGroup.Allrightsreserved.STEPHENSAUER
U P D AT E D

2. Deep Dive
InfoWorld.com deep dive series 2PA A S
iOS
vs.
Android
vs.
BlackBerry
vs.
Windows
Phone
Deep Dive
2InfoWorld.comM o b i l e S ec u r i t y
Google’sAndroidfor
WorkandSamsung’s
Knoxpromiseserious
security,buthowdothey
stackupagainstApple’s
iOSandtherest?
BY Galen Gruman
Mobile
security

3. Deep Dive
InfoWorld.com deep dive series 3PA A S
Apple’s iPhoneand iPad long ago pushed
out the BlackBerry as the corporate standard for
mobile devices, in all but the highest-security
environments. Earlier this year, Google — whose
Android platform reigns outside the corporate
world — got serious about mobile management
with a new effort called Android for Work. And
Samsung upped its the game with a new version
of its Android security suite, Knox.
Now we have Android 6.0 Marshmallow and
iOS 9, both of which offer refinements to their
respective existing mobile management capabili-
ties, particularly in the areas of app management.
What’s new in iOS 9
Released in mid-September, Apple’s iOS 9 has
very few new policies for managing iPhones,
iPads, and iPod Touches. But there are a few:
Using an mobile device management (MDM) tool,
IT admins can now force iOS updates as well as
stage their deployment across supervised devices
— corporate-issued devices under full IT control.
There are also new policies in iOS 9 to control
whether devices can roam on cellular networks,
to enable or disable screen recording, and to
control whether they can use Apple’s Mail Drop
feature to send large attachments. (Mail Drop
stores the documents in iCloud and sends the
recipient not using an Apple device a link instead
to download the attachment from; Apple device
users see the normal attachment in their email,
even if it exceeds their email server’s attachment-
size limits, because Apple Mail reattaches the file
automatically behind the scenes.)
For supervised devices only, there are new
controls over Apple Watch pairing, the use of
iCloud Photo Library, keyboard shortcuts, auto-
matic app downloads, and News app setup, as
well as over the users’ ability to change the device
name, password, and wallpaper. Those super-
vised policies are designed mainly for shared-use
devices, such as in schools or retailers.
Apple’s major changes in iOS 9 manage-
ment focus on its Device Enrollment Program
and Volume Purchase Program services. DEP
is the service to manage fleets of supervised
iOS devices and in-house apps, and VPP is the
program to manage corporate apps from the
App Store across that fleet of devices.
iOS 9 adopts the OS X approach to app
management, whereby IT can associate a specific
app to any number of devices and/or users,
rather than managing each device’s or user’s
apps independently. Apple has also simplified
how DEP catalogs apps, so IT can build an app
library without having to poll all devices each
time. Apps can now be installed on supervised
devices even if the App Store is disabled on
those devices, and in-house apps can be installed
silently, without user confirmation.
What’s new in Android 6.0
Marshmallow
The big change in Android Marshmallow is that
its adopts iOS’s approach to app permissions.
That means users can now change the permis-
sions that apps have whenever they want, not
just choose those permissions at app installation.
Many users didn’t know what all
those requested permissions meant,
plus they had to accept all or none.
Now, users can go to the Settings
app to see what permissions each
app uses and revoke or enable each
permission independently.
Better, IT can also manage these
app permissions just as granularly
for apps that reside in Android for
Work or other managed container
(for BYOD deployments) or on fully
managed (supervised) corporate-
issued devices, notes Imran Ansari,
Android product manager at MDM
Deep Dive
M o b i l e S ec u r i t y InfoWorld.com deep dive series 3
Get More Mobile Thought Leadership
• Samsung Knox 2.4 vs. Google Android for Work
• How to rethink security for the new world of IT
• Real data security for all is now getting its start on mobile
• Mobile and PC management: The tough but unstoppable union
• Mobile management: Making sense of your options
• Unchain your mobile users and just protect the data
• Liquid computing: The next wave of the mobile experience
• Consumerization of IT: How IT should manage personal technology at work

4. Deep Dive
4M o b i l e S ec u r i t y InfoWorld.com deep dive series
provider Soti.
Android Marshmallow’s other
policy refinements are similar in
their incremental nature to iOS
9’s. For example, new policies
let IT force a device’s screen to
stay on or a Wi-Fi connection to
remain active while the device
is plugged in. Ansari says that
this feature will appeal to IT for
public-facing deployments, such
as for kiosks, payment terminals,
ordering systems, and lobby
sign-in systems.
Android Marshmallow also lets admins
disable the use of a smartwatch as an authenti-
cation token, so a smartwatch cannot be used
to bypass a password requirement. And it lets IT
force installation of OS updates as they become
available, as well as delay those updates for as
long as 30 days, so IT can test apps on a new OS
version first.
Finally, Android Marshmallow offers new
policies to control whether users can safe-boot
their device (booting into safe mode can bypass
MDM controls) and to control whether notifica-
tion details can appear on a paired smartwatch’s
screen, to keep company information secret.
What Android for Work does
and doesn’t do
The biggest change in Android management,
however, came last February with the release
of Android for Work as part of an Android 5
Lollipop update. That technology added new
security and management capabilities, plus the
ability to do corporate deployments of Android
apps from the Play Store.
Android for Work containers — which run
business apps in a separately managed work-
space on your device — are part of the Android
5 Lollipop and Android 6 Marshmallow OSes
and support any Google Play store apps. But
Android 3.0 Ice Cream Sandwich through 4.4
KitKat require users to install the Android for
Work app, which can run only apps that have
the Android for Work APIs implemented.
Either way, you need a compatible mobile
management server to handle the policies
applied to apps running in the container, such
as enforced VPN use or copy-and-paste restric-
tions. Mobile management vendors supporting
Android for Work include BlackBerry, Citrix
Systems, Google, IBM, MobileIron, SAP, Soti,
and VMware AirWatch.
What Android for Work only partially
addresses is the malware problem among
Android apps, both due to the high incidence
of malware residing in the Google Play Store
and to the common file system in Android
that lets malware infect apps via data files. For
example, the feds have said that industrial-class
spyware used in advanced persistent threats has
entered the Google Play market. With Android
for Work, IT admins can prevent users from
installing unapproved apps from the Play Store
in the business workspace to better protect the
corporate environment.
By contrast, iOS uses rigid sandboxing to
keep apps from accessing other apps, and it
severely restricts document sharing to block
malware. BlackBerry and Windows Phone have
small app libraries and a semiporous approach to
sandboxing, so malware has not been an issue
for them to date — though there have been
outbreaks of BlackBerry malware in the past.
Android for Work also does not make
encryption the default on existing Android
devices (many models, especially the cheap ones,
lack the horsepower to handle encryption).
Google promised last October that Android
5 Lollipop would enable encryption by default
on all new devices. (Upgraded devices’ encryp-
tion state is unchanged.) But there’s no require-
ment that the devices use a crypto chip, so users
could see major performance hits. InfoWorld’s
Apple’s
approach
istohandle
appsand
theircontents
directly,which
meansapp
developers
mustimplement
theAPIsfora
management
servertobeable
toworkwith
them.
Android for
Work capabilities
A two-page guide to the management
capabilities that Android for Work enables IT
admins to apply to content and apps.
S o u r c e : M o b i l e I r o n
D o w n l o ad

5. Deep Dive
5M o b i l e S ec u r i t y InfoWorld.com deep dive series
Policy
Apple
iOS 7, 8, 9
Google
Android 4, 5, 6
Samsung
Android 5
+ Knox
BlackBerry
BlackBerry 10
Microsoft
Windows
Phone 8, 8.1
Allow device encryption Yes Yes Yes Yes Yes
Require device encryption Yes Yes [1] MDM Yes Yes
Encrypt storage card NA Yes Yes Yes Yes
Minimum password length Yes Yes Yes Yes Yes
Minimum number of complex
characters (password)
Yes Yes Yes Yes Yes
Password history Yes Yes Yes Yes Yes
Device wipe threshold Yes Yes Yes Yes Yes
Disable removable storage MDM No MDM MDM No
Disable camera Yes Yes Yes MDM No
Disable SMS text messaging No No MDM MDM No
Disable Wi-Fi MDM No MDM MDM Yes [2]
Disable Bluetooth MDM No MDM MDM No
Disable IrDA NA No No No No
Require manual sync while
roaming
Yes No Yes MDM No
Allow Internet sharing from
device
MDM No MDM MDM MDM
Allow desktop sharing from
device
MDM No MDM No No
Disable email
attachment access
Yes MDM Yes No Yes
Disable POP3/IMAP4 email MDM No MDM Yes No
Allow consumer email No No MDM Yes No
Allow browser Yes MDM MDM No MDM
Configure message formats
(HTML or plain text)
No No MDM No No
Include past email items
(days)
Yes No MDM Yes Yes
Email body truncation size
(KB)
No No MDM No Yes [2]
HTML email body
truncation size (KB)
No No MDM No Yes [2]
Include past calendar items
(days)
Yes No MDM
Yes No
Require signed S/MIME
messages
Yes No MDM MDM Yes [2]
Require encrypted
S/MIME messages
Yes No MDM
MDM Yes [2]
Require signed S/MIME
algorithm
Yes No MDM MDM Yes [2]
Require encrypted
S/MIME algorithm
Yes No MDM
MDM Yes [2]
Allow S/MIME encrypted
algorithm negotiation
Yes No MDM
MDM Yes [2]
Allow S/MIME soft certs No No Yes MDM Yes [2]
Exchange ActiveSync (EAS)
policy support compared
(“MDM” means a separate mobile device management server is required)
[1] Storage areas only. [2] Windows Phone 8.1 only.

6. Deep Dive
InfoWorld.com deep dive series 6M o b i l e S ec u r i t y
sister publication Greenbot found that Google’s
own Nexus 6 slows to a crawl with encryption
on, for example.
Of particular concern to IT, Google has quietly
backtracked on its promise that new Lollipop
devices would be encrypted by default. In fact,
several new Lollipop devices are not. The new
Android Marshmallow also does not enforce this
promised encryption.
By contrast, iOS devices have been encrypted
by default (with no disable option) since 2010,
and BlackBerry devices have been encrypted for
at least a decade — both have the needed crypto
chip to avoid performance hits. But Windows
Phone 8.1 devices come with encryption disabled
by default, and an admin must enable it.
(Windows 8.1 is the first version of Microsoft’s
mobile platform to support device encryption.)
It’s unclear whether the forthcoming Windows
Phone 10 will enable encryption by default.
Knox aims for corporate-issued
Android users
Announced two years ago, Samsung’s Knox
has had a difficult rollout and now has Google’s
Android for Work competing with it. But the
company has stuck to the product, quietly
unveiling the new Knox 2.4 version this month.
Knox works only with selected smartphones
and tablets from Samsung, because it integrates
directly with the hardware in a way similar to
how BlackBerry does for its own smartphones
and BES management server. Thus, Knox is a
realistic option only for companies that issue
compatible Samsung devices to employees.
For such companies, Knox 2.4 (which runs
only on Android Lollipop devices) provides Active
Directory password integration for its secure
workspace, bulk enrollment of devices over the
air, and the ability to track users’ business and
personal data usage.
Mobile device management has
essentially stabilized
Google’s Android for Work move came on the
heels of the efforts of Microsoft to improve the
security of Windows Phone, which historically
has had weak security and management capa-
bilities. Windows Phone 8.1, released last fall,
finally gave the Microsoft smartphone platform a
reasonable level of basic capabilities, though well
behind what other mobile platforms provide.
BlackBerry devices have long offered mobile
device management (MDM) controls in the oper-
ating system and key bundled apps to manage
user permissions. iOS added such capabilities in
2010. Android followed a few years later, and
in fall 2014 Windows 8.1 was the last major
mobile OS to provide a strong set of device-
management APIs. (BlackBerry devices also
provide a secure network and chip-level antide-
vice spoofing, which competitors don’t have and
are key reasons that high-security environments
rely on BlackBerry still.)
With the market for BlackBerry devices fading
fast, BlackBerry has focused on reshaping its
formerly BlackBerry-only BES tool into a unified
mobile management tool, BlackBerry Enterprise
Service (BES) 12, for managing iOS, Android, and
Windows Phone 8 devices — all widely supported
by other MDM tools — in addition to its current
BlackBerry 10 and legacy BlackBerry 5 and 7
devices. But BES12 has failed in the market-
place, causing BlackBerry to buy long-time MDM
provider Good Technology instead.
Also, iOS, Android, Windows Phone 8, and
BlackBerry 10 all support Microsoft Exchange
ActiveSync (EAS) policies, which provides basic
but common cross-platform management for
less-rigorous security environments that IT can
administer from an Exchange server, Office
365, Google at Work, Lotus Notes, or Microsoft
System Center, as well as from any MDM server.
Table 1 shows which policies are supported by
each major mobile platform.
Content and app management is
where mobile security is now focused
These days, the mobile management vendors’
focus is on content and application security since
device management is all but settled. Apple’s
iOS 7 APIs were the first to address the issue at a
platform level, providing standard APIs for apps
to use to manage their content and usage.
Apple last made a big leap in mobile security
and management in 2013, when iOS 7 pushed
Apple’s management and security into new
areas, including application management and
APIs vary
widely across
the major
mobile OSes,
and each
requires a
management
tool.
Most MDM
tools support
multiple
mobile OSes,
providing a
single console
for IT admins.

7. Deep Dive
InfoWorld.com deep dive series 7M o b i l e S ec u r i t y
Capability
Apple
iOS 7, 8, 9
Google
Android 4, 5, 6
Samsung
Android 5
+ Knox 2.4
BlackBerry
BlackBerry 10
BES12
Microsoft
Windows
Phone 8, 8.1
Encryption AES 256, user has no
disable option
AES 128, user has
disable option, only
some models support
encryption
AES 256, user has
disable option, only
Knox devices support
encryption
AES 256, user has
disable option in
personal workspace
AES 256, user has no
disable option
FIPS 140-2 certification Yes
(Level 1)
No Some models
(Level 1)
Yes
(Level 2)
Yes
(Level 1)
Over-the-air data encryption Yes Yes Yes Yes Yes
S/MIME Yes No Yes Yes Yes [2]
VPN Yes Yes Yes Yes Yes [2]
Configure VPN Yes Yes Yes Yes Yes [2]
Per-app VPN Yes Yes [3] Yes Yes Yes [2]
Restrict/block app stores Yes No Yes Yes Yes
Business licensing and provi-
sioning
Yes Yes [3] Yes [3] Yes No
Restrict/block wireless LANs Yes No Yes Yes Yes [2]
Configure allowable access
points
Yes Yes Yes Yes Yes [2]
Signed apps required Yes No Yes Yes Yes
Selective wipe of business
apps and data only
Yes Yes [3] Yes Yes Yes [2]
Remotely update business
apps
Yes Yes [3] Yes Yes Yes
Secure boot Yes Yes [1] Yes Yes Yes
Active Directory container
signin
NA No Yes [3] No No
App sandboxing Yes Yes Yes Yes Yes
Disable copy and paste Yes Yes Yes Yes Yes [2]
Disable iCloud/Microsoft
Account/Google Account
sync and storage
Yes No Yes Yes Yes [2]
Disable data roaming Yes [4] No No Yes No
Disable smartwatch pairing Yes [4] Yes [5] Yes NA NA
Other native management
capabilities compared
(Typically requires a mobile device management server to use)
licensing management. The recent iOS 8 and iOS
9 have only a few additions.
Apple’s approach is to handle apps and their
contents directly, which means app developers
must implement the APIs for a management
server to be able to work with them. Furthermore,
iOS allows only one instance of an app on a
device, so users can’t install a personal copy free
of restricts and a business copy managed by IT.
Apple didn’t invent the API-managed apps
notion; in 2011 several startups offered mobile
application management technology that required
[1] Added by some smartphone makers.
[2] In Windows Phone 8.1 only (and VPN support is partial).
[3] In secured container only.
[4] Supervised devices running iOS 9 only.
[5] Android 6 only.

8. Deep Dive
InfoWorld.com deep dive series 8
It’s a no-brainer
that iOS and
BlackBerryOS
have what it
takes for almost
any business’s
security needs.
M o b i l e S ec u r i t y
app developers to implement proprietary APIs
and proprietary management tools. They went
nowhere. Apple’s approach in iOS 7 makes the
technology available to all apps and all manage-
ment servers, eliminating the lock-in barrier.
Since then, most vendors have taken the
containerization approach, which essentially
partitions IT-managed apps and the data they
work on, into a separate workspace not acces-
sible by the user’s personal apps. Users have to
switch between the two workspaces, as if they
were using two devices.
For years, several providers such as Divide have
offered such containers for iOS and Android, but
they required that the apps running in them be
tied to their proprietary APIs, which in turn were
tied to a specific vendor’s mobile management
server. Thus, they’ve gained little adoption.
In 2013, Samsung announced a container
technology called Knox that was available
for a handful of its Galaxy smartphones and
supported by few mobile management servers,
so it too has gained very little adoption. But the
company is renewing its Knox effort with the 2.4
version released on April 10, 2015.
Also in 2013, BlackBerry introduced
BlackBerry Balance, the first platform-level
containerization approach, for BlackBerry 10
devices. It also has a Balance container app,
called Secure Work Space, for iOS and Android.
In spring 2014, Google purchased contain-
erization vendor Divide and later said it would
make containerization part of Android — now
the Android for Work technology that became
available in February 2015.
Container policies differ widely from
container to container, which can make manage-
ment difficult. However, now that popular
mobile management servers support both iOS’s
APIs and Android’s containers, IT admins should
be able to create consistent policies that are
largely compatible across the two platforms
— much as they can when using the extended
device management APIs in iOS and Android.
Note that BlackBerry’s BES12 supports some
of the iOS 7 app-management APIs, few than
those from, for example, Citrix, MobileIron, and
VMware AirWatch. Among the iOS 7 app poli-
cies supported by BES12 are per-app VPN, single-
app mode, single sign-on, and Apple Volume
Purchase Plan (its corporate app store).
BES12 supports some app-management APIs
for BlackBerry devices, but the policies available
vary widely based on the type of app managed:
Java, recompiled or Fire OS-compatible Android,
BlackBerry 5- or 7-native, or BlackBerry
10-native. Frankly, it’s a mess.
Native security and management
API capabilities compared
As noted previously, the platform APIs vary
widely across the major mobile OSes, and each
requires a management tool. Most MDM tools
support multiple mobile OSes, providing a single
console for IT admins.
Some also offer client apps — basically, a
proprietary container with proprietary business
and communications apps — that add capabilities
not found in the native APIs. Table 2 shows some
of the more commonly requested management
features typically implemented through APIs.
iOS API tour. Apple, for example, has
several dozen APIs for device management that
use remotely installed configuration profiles not
only to configure various iOS settings (such as
preconfiguring VPN or allowed access points)
but also to manage app behavior (such as disal-
lowing the forwarding of corporate messages via
personal accounts in Mail). App-related policies
include the ability to prevent app removal, lock
a user to a specific app (such as for kiosk or
retail usage), and prevent paid apps from being
purchased. All are part of what iOS calls a super-
vised environment, in which the iPhone or iPad is
treated as an appliance.
iOS’s APIs for application management
include managed Open In, per-app VPNs,
managed copy and paste across apps, and single
sign-on, as well as true license management and
profile-based app installation. iOS 8 also has APIs
to disable the new Handoff capability, iCloud sync
for managed apps, backup of enterprise books,
and annotation to enterprise books. Supervised
devices also get the ability to disable erasure of
all content and settings, restriction configuration,
and presentation of Web results in a Spotlight

9. Deep Dive
InfoWorld.com deep dive series 9M o b i l e S ec u r i t y
search. iOS 8 supported per-message S/MIME
and both IKEv2 and always-on VPNs, as well. iOS
9 adds several features, as previously described,
such as control over cellular roaming, use of
MailDrop, and iOS updates.
Android API tour. Although Google
hasn’t published details of its Android at Work
APIs on its Android developer or IT admin sites,
Alexander Romero, an Android engineer at
MobileIron, walked me through them.
To address the Android malware problem,
Android at Work can let IT restrict the provi-
sioning of apps in the business workspace to
only those approved by IT. That means users
can’t install apps themselves in the secured
workspace if IT enables this policy. IT can also
install, update, and remove apps in the business
workspace without user involvement.
There are policies to disable copy and paste
from the business workspace into the personal
one (but not vice versa) and to prevent screen-
shots being taken in the business workspace. IT
can also determine which IT-managed apps use a
VPN for access, as well as retract personal apps’
communication from the corporate VPN.
Android Marshmallow adds, as previously
noted, a few policies, such as to deploy OS
updates to managed devices and to manage app
permissions.
Google also says the Google Play app store
can now provision apps to Android devices
through volume business licenses, similar to
Apple’s volume licensing approach introduced in
iOS 7. Called Google Play for Work, the revised
app store supports free apps already and will
“soon” support paid apps.
Samsung had its own set of device APIs
for Android 4 called SAFE APIs, which allow IT
admins to disable cameras, Bluetooth, tethering,
voice recording, SD cards, and Wi-Fi. You have
to use a SAFE-compatible device and manage-
ment server to use those extra policies. The SAFE
APIs were replaced with its similar Knox APIs in
Android 5.
Windows Phone API tour. In Windows
Phone 8, Microsoft supports the ability to revoke
applications, restrict email forwarding, remotely
enroll or unenroll devices, and remotely update
business-provisioned apps.
One capability in Windows Phone 8 not
available to other mobile OSes is its integration
with Active Directory. This means that compat-
ible MDM tools can access the Active Directory
groups, then assign policies to those groups
rather than maintain a separate set of groups in
the MDM tool from the set in Active Directory.
The feature reduces the risk of employees not
being in the correct groups for the policies that
should apply or falling through the cracks when
terminated in, say, Active Directory but not in the
MDM tool’s user database.
Microsoft uses a central manager in
Windows Phone 8 called DM Client that contains
all the relevant user and corporate profiles (like
the Windows Registry, in effect), rather than
rely on a set of separate installed configuration
profiles (like the OS X System Folder, in effect).
How to think about mobile device
management
No matter what platforms you support, there are
three bands of management requirements for IT
to think about, advises Ojas Rege, vice president
of strategy at MobileIron.
The first set of requirements is around
configuration and protection of lost or compro-
mised devices. That typically requires password
enforcement, encryption enforcement, remote
lock and wipe, remote email configuration,
certificates for identity, remote connectivity
configuration (such as for Wi-Fi and VPNs,
though Rege says this configuration capability is
not essential if usage is only for email and over
cellular networks), and detection of compro-
mised OSes (whether jailbroken, rooted, or
malware-infected).
The second set of requirements is around
data loss prevention (DLP), which covers privacy
controls (such as for user location), cloud-usage
controls (such as for iCloud, OneDrive, and
Google Docs), and email DLP controls (such as
the ability to restrict email forwarding and to
protect attachments). “More regulated environ-
ments may require No. 2, and these policies
are still TBD for Windows Phone,” Rege notes.
By contrast, iOS, BlackBerry, and Android have
supported most of these needs since (respec-
tively) iOS 4, BES 5, and Android 3, though a few

10. Deep Dive
InfoWorld.com deep dive series 10M o b i l e S ec u r i t y
— for example, managing email forwards — are
handled outside the OS by MDM client apps
such as MobileIron’s.
The third set of requirements is around apps,
such as their provisioning and data security. Both
Apple and Microsoft have mechanisms to do at
least basic app management — iOS can essen-
tially hide an app so that it’s no longer available
to a user, and Windows Phone 8 can update
corporate apps remotely — and both Google
and Samsung now offer this capability within
their secured containers.
But mobile application management (MAM)
capabilities are mostly still up to the mobile
management vendors to deploy and can vary
widely across MDM tools, Rege says.
All four platforms provide mechanisms for
businesses to deploy their own apps directly to
users, so they can deploy and manage corpo-
rate apps separately from those that users get
from the app store. (Apple, Google, and now
Samsung have volume licensing and distribution
mechanisms in place.) Mobile management tools
can connect these mechanisms to group policies
and content-management controls.
It’s a no-brainer that iOS and BlackBerry OS
have what it takes for almost any business’s
security needs, even if it doesn’t have much in
the way of apps that would make users want
it. Android, especially with Android for Work or
Knox 2.4 or later in use, is a plausible platform
— and they reduce the malware potential at
least in the secured container part of the device.
And Windows Phone, which has long held
down the rear, is becoming more appropriate for
midlevel security requirements. n
Galen Gruman is an executive editor at
InfoWorld and its columnist on mobile and
consumerization of IT.

11. Deep Dive
InfoWorld.com deep dive series 11
Mobileand
PCmanagement:
Thetoughbut
unstoppableunion
M o b i l e S ec u r i t y
Oneday,you’llmanageall
clientdevicesfromacentral
policyconsole,butitwon’t
beafastoreasyjourney
By Galen Gruman
You know that a trend has peaked when the
establishment jumps on board. That’s happening in
the world of mobile management, pioneered years
ago by niche companies such as Good Technology
and Zenprise and startups like MobileIron and
AirWatch. Now, establishment companies such as
CA Technologies, Citrix Systems (which bought
Zenprise), Dell, EMC VMware (which bought
AirWatch), IBM, and Microsoft are aggressively
pushing their mobile management tools.
Just as the establishment is getting into mobile
management (aka MDM), the field itself is poised
for a shift away from mobile only. Tablets, both
the category-defining iPad and the “deconstructed
laptops” promoted by Microsoft and other
Windows device makers, are both like smartphones
and like laptops. For some people, they replace
laptops; for others, they supplement them. In any
event, the lines between computers and mobile
devices are blurring.
Even where there are clear divisions, users are
working with multiple devices. Suddenly, any sepa-
ration on the management side gets hard to keep
separate in reality — password, access, and other
policies overlap hugely, no matter if the tools don’t.
STEPHENSAUER

12. Deep Dive
InfoWorld.com deep dive series 1 2
That’s why
MDM is
shifting away
from mobile
to encompass
anything and
everything
a user might
access: smart-
phones, tablets,
computers,
even cloud
desktop
services.
M o b i l e S ec u r i t y
That’s why MDM is shifting away from
mobile to encompass anything and everything
a user might access: smartphones, tablets,
computers, computers, even cloud desktop
services. Some are personally owned, some
are work-owned, most are mixed-use in prac-
tice. They cover a range of operating systems:
multiple versions of Windows, OS X, iOS, and
Android for sure, perhaps Linux, Windows
Phone, Chrome OS, and BlackBerry OS as well.
But getting to that state of universal
client management is not easy. Fundamental
technology differences exist on these clients,
affecting what can be secured and managed
and how it can be secured and managed. Still,
vendors are moving in that direction because,
they say, large businesses have decided that in
the not-too-distant future they would like to end
the separate PC and mobile silos and manage
devices collectively.
When it comes to management,
Windows is not like the others
What would it take for a tool to truly be unified?
The reality is that Windows is managed using
very different technologies and assumptions than
the other popular operating systems are. The
reasons are historical and deep: “In the carrier
context for mobile, you couldn’t worry about
the OS — the carriers did it. But in Windows,
you always had the control over it,” recalls Neal
Foster, executive director of product marketing
for mobile management at Dell.
Outside of Windows and BlackBerry’s tradi-
tional BES, the typical approach is to deliver a
payload to a device containing policies. From
there, the device implements those policies
through its standard APIs. It’s an approach that
CA’s Varadarajan calls simplex: You push out
the policy package and it gets implemented
whenever the device receives and “digests” the
payload. When the device later tries to access
your servers, a policy check is done to see if the
correct policies are in place.
This payload approach is great for mobile
devices because you can issue them whether
or not you have a connection — in fact, you
can issue them when you don’t have a connec-
tion, so you don’t have to provide a safe space
first to even deliver the policies. But you have
no constant monitoring such as for compliance
auditing; you only know when a device tries to
connect what policies it reports are installed.
Apple and others have made such payloads
undeletable by users, but it lacks the constant
assurance that some industries seek.
Windows assumes a very different world, one
where computers are inside a trusted firewall,
don’t leave the trusted network, and in fact are
treated as an attached node, not an occasional
guest. That’s the fundamental notion behind the
domain join managed through Active Direc-
tory and System Center. Of course, over time
as laptops became popular, Windows manage-
ment had to adapt to handle access over outside
networks, typically using VPNs to extend the
trusted network through the Internet.
The domain-join approach allows for more
active engagement between the client and the
server, as well as for more constant auditing. But
it does poorly in the in-and-out world of mobile
devices, which explains why even Microsoft hasn’t
used the domain-join approach in Windows
Phone and Windows RT. “The domain join for
PCs implied a context for environment,” says
Dell’s Foster, “but more and more, PCs are not
connected via a domain, so that context is gone.”
It’s telling that Microsoft doesn’t use domain
joining in its mobile-oriented mobile manage-
ment tool, Intune. Instead, it uses a client app
on the PC that basically consumes the payloads,
then configures Windows accordingly and acts
as a safe space, similar to the sandboxes used
natively in iOS and OS X and via third-party soft-
ware in Android.
Over time, the payload approach may
become the standard approach, even in
Windows. Microsoft’s Windows OS team
declined to speak to InfoWorld about its views
on management, and the server group didn’t
want to speak for the OS group. But “with
Windows 8.1, it’s possible to manage a PC like a
mobile device, such as by laying down an agent
to do System Center stuff or use a management
API. Windows RT does that, too,” says Andrew
Conway, director of product marketing at Micro-
soft for Windows Server and System Center. Yet
Windows Phone 8.1 does support domain joins,

13. Deep Dive
InfoWorld.com deep dive series 1 3
Most companies don’t manage desktop
and mobile from the same team.”
Ram Varadarajan, general manager at CA
M o b i l e S ec u r i t y
so Microsoft may also be trying to keep both
approaches available as the market continues to
experiment.
The path to unified management
Certainly, the MDM pioneers see the shift to
unified management coming, and several have
expanded their mobile offerings to include Macs,
since Apple has unified many of the APIs across
iOS and OS X to simplify the process. Many
partner with other providers to offer not a truly
integrated suite to cover PCs and mobile, but a
twinned product set that allows some sharing or
coordination of policies.
But it’s the establishment providers who are
most active in trying to reconcile the desktop
and mobile worlds into a common management
environment, covering everything from asset
tracking to security policy enforcement, for a
simple reason. These establishment providers
typically have Windows-oriented tools, covering
the vast majority of client devices in the work-
place and providing a starting point most
familiar to IT: Windows PCs. (Microsoft says that
70 percent of enterprises today use its System
Center for that purpose.)
Their offerings run the gamut from pairing
two separate tools with some commonalities,
such as policy sharing or common admin console,
to a single tool that handles client differences
behind the scenes. Most organizations still
have separate teams managing PCs and mobile
devices, and the single-tool approach works only
when an enterprise ends that separation.
“Most companies don’t manage desktop and
mobile from the same team. Desktop manage-
ment has been around a long time, and PC
management is considered a normal activity,
whereas mobile is considered something new
and done by a separate team,” notes Ram
Varadarajan, general manager at CA. “We’re not
seeing a propensity to go to one management
system in one shot, but as a phased evolution,”
says Dell’s Foster.
That poses a chicken-and-egg dilemma for
providers. Right now, mobile devices are managed
by a different team than PCs are. Mobile devices
quickly fell into the domain of Exchange admins
as the early mobile use cases were around email,
and Apple adopted Microsoft’s Exchange Active-
Sync protocol as its default management tech-
nology, which Google then did for Android.
Thus, IT organizations typically seek two
tools even as they talk about eventual unifica-
tion. “We’re seeing a trend toward more unified
management,” notes Microsoft’s Conway. “Most
corporations don’t want this island of mobile any
more; they want to treat it all as one,” says CA’s
Varadarajan.
But until they unify the IT teams, a unified
tool doesn’t make a lot of sense. The answer, of
course, is for IT to centralize the management
team first, bringing whatever tools are in place
to that unified team. From there, IT can consider
replacing those tools with a unified management
tool as vendors begin to provide them.
CA, Dell, and Microsoft are good examples of
how management providers are trying to move
to a unified management approach. Chances are
that the providers you’re talking to or working
with fall within the continuum they represent.
CA is looking to provide a single console
for all management, notes Varadarajan. The
platform differences get hidden behind the
scenes, and the easiest places to unify are where
platforms share policies even if their execu-
tion differs. “We do see already a common
management tool for OS X and Windows. iOS
and Android are not that different,” he says,
suggesting that the unification challenge is easier
than you may assume because there’s already
some convergence across platforms on key attri-
butes. “Sure, the measures and implementations
we use might be different. For example, we have
different agents on Windows, OS X, and mobile,
but they do largely the same things.”
In other words, providers will need to fork
their tools internally. “Forking is a skill that is
underrated, but it has to be embraced for higher
goal of uniformity,” Varadarajan says. As an
‘‘

14. Deep Dive
InfoWorld.com deep dive series 14
Hoping to
impose a
common set of
devices, appli-
cations, and
services is a
pipe dream.
But that doesn’t
mean IT
shouldn’t seek
unity.
M o b i l e S ec u r i t y
example, “OS X and iOS use many of same APIs
but different semantics. I expect the same thing
in Android PCs over time, and I can see the
possibility in Windows given Windows Phone’s
big differences with PC Windows.”
Of course, some policies simply don’t apply
to some devices, but a unified tool would know
that and would ignore irrelevant policies while
flagging policies that are relevant but can’t be
deployed to a specific device. A crude example
of that is Apple’s OS X Server, whose manage-
ment console arranges its policies in three
groups: iOS, OS X, and iOS and OS X. Enterprise-
class tools will treat these differences more
elegantly, but they will exist.
Varadarajan also notes that the client isn’t
the only part of the equation. You have servers
and network appliances, and they can do a lot of
the work when devices connect, such as moni-
toring traffic, validating access, and enforcing
policies on the server side directly. Back-end
management is key to unified device manage-
ment, because all the devices work through that
back end, which is the gateway to the company
information and services.
Microsoft is taking two paths: extending
its traditional System Center to the new, more
intermittent world and delivering a payload-
oriented tool via Intune. But it’s not an either/or
proposition. Intune can be used to manage PCs,
not just mobile devices, via a client app, though
its primary use case is for mobile devices, notes
Microsoft’s Conway. The PC-focused System
Center can be used in concert with Intune
on mobile devices, so System Center handles
the asset management and configuration and
Intune handles the deployment of security and
device policies.
Windows 8.1 starts Microsoft’s PC OS down
the path that Apple began with OS X Lion: using
APIs for mobile-style payload-based management.
Dell’s approach is the most traditional: It has
a basket of specific tools for various manage-
ment needs, some for mobile, some for PCs,
some for both. Customers pick the tools they
need, whether or not their teams are unified,
and Dell offers consulting services to integrate
the tools for the customer’s specific needs.
“We’re finding that customers are all very
different, so there’s a lot of custom work, à la
professional services,” says Dell’s Foster.
Unified management does not mean
managing a unified technology stack
The computing world is one of heterogeneity, a
mix of device types, operating systems, applica-
tions, and services. The notion that everyone
uses a standard PC with a standard OS image
and application set is quaint — and on its way
out. “You have to embrace heterogeneity. If you
are angry with heterogeneity, you are doomed,”
says CA’s Varadarajan.
Cloud storage is a great example of that
notion, says Dell’s Foster, citing Office 365,
Google Drive, and Apple iWork. “But no one
does it all well, so users tend to mix and match.”
That same mixing and matching applies to
applications, devices, and other services because
no single platform does everything well. That’s
going to be a true for a long time, especially
because technology has gotten so personal that
there is rarely one best set of tools even for
people doing similar jobs.
Hoping to impose a common set of devices,
applications, and services is a pipe dream. But
that doesn’t mean IT shouldn’t seek unity. IT
just needs to look elsewhere. Common poli-
cies are one place to look. But there are others.
“The greatest thing that has been adopted are
single-sign-on models like OAuth and SAML. So
the way you get control is not by proxying but
managing the access in the first place,” Foster
says. You pair that higher-level standardization
with what Foster calls “endpoint posture” —
ensuring that permitted devices meet your stan-
dards on issues such as passwords, encryption,
data isolation, and identity validation — then
you put both in a common policy framework on
permitted access based on role and other factors.
Ironically, the path to unified management
goes through an embrace of diversity and
heterogeneity. There are enough commonalities
to create a management fabric. But both the
vendors and IT need to approach it that way. n
Galen Gruman is an executive editor at
InfoWorld and its columnist on mobile and
consumerization of IT.

15. Deep Dive
InfoWorld.com deep dive series 1 5M o b i l e S ec u r i t y
PC sales continue to decline, mobile
sales continue to climb, people work at
home, and the notion of strict work/life
separation for equipment is on its way
out for many information workers.
Yet most IT organizations and
security vendors insist on applying
legacy thinking for information security
that simply cannot work in the modern world of
heterogeneous, anywhere, and mixed personal/
business computing. They keep trying to build
mobile prisons, extending perimeter defenses
across the digital world or creating satellite
fortresses on every device. No one willingly
enters a prison, and the gulag and straitjacket
approaches favored by IT and security vendors
simply will be bypassed by business users,
who’ve been doing so for years on the desktop.
It’s time to stop the madness and protect
what really matters: the information that moves
among all the devices. To do so, the industry
needs to stop trying to turn smartphones into
fortresses that people can’t use and forcing the
use of proprietary app containers that can’t scale
a heterogeneous, interconnected digital
environment or that provide read-only
access (what’s the point, then, of having the
file?). Instead, it’s time we focus on protection
at the information level, essentially using the
notion of digital rights management (DRM) that
travels with the data itself. The only way to make
that work is through an industry standard.
There are two great models for how this can
work. One is Microsoft’s Exchange ActiveSync
(EAS) protocol, which provides a de facto stan-
dard for basic device security that ensures good
security hygiene such as forced device encryption
and enforced password use. This single protocol,
if broadly adopted, gets rid of most of IT’s often-
stated “what if the user loses the device?” fear.
The other is the Wi-Fi Alliance, the group
ensuring interoperability of the 802.11 devices
that in the beginning could not talk to each
other though they were based on the same IEEE
standard. The alliance is now trying to create
the same assurance of interoperability for video
streaming via its Miracast standard. By having an
interoperable information-level security standard,
Unchainyour
mobileusers
andjustprotect
thedata
ITandthe
securityindustry
arebothfocused
ondubious
protectionplans.
Thisproposed
standardshowsa
betterway
By Galen Gruman

16. Deep Dive
InfoWorld.com deep dive series 16
Authoring and
editing tools
should be able
to assign both
usage rights
and two of the
access rights:
the password
require-
ment and the
encryption
requirement.
M o b i l e S ec u r i t y
IT would be assured that critical information
remains protected no matter what apps are
accessing it and no matter on what devices.
Today, we have a muddle of competing
proprietary standards from more than a dozen
companies. Their containers typically work only
with IT-developed apps that use their specific
API and management tool, and sometimes
with commercial apps that adopt that propri-
etary technology. That proprietary nature puts
everyone at risk: IT and developers are wed
to a single company in a frothy market where
vendors come and go. Users are severely limited
in the apps and devices they can use — most
of these systems, for example, don’t work on
Windows or OS X, even though PCs remain
the biggest source by far of data loss, whereas
mobile is a minor factor.
Some in the security industry understand
that today’s mobile device management (MDM)
and mobile application management (MAM)
tools can’t both protect information and support
realistic work scenarios. MobileIron, for example,
has floated the idea of an industry standards
group to define an information-level security
standard. It’s a good suggestion, but it should
not be limited to mobile — and it needs to work
like the Wi-Fi Alliance in that it doesn’t become
a lip-service standards group vendors use to
delay interoperability in hopes their proprietary
platform might “win” in the meantime.
Any such standard also needs to avoid scope
creep. There’s a place for MDM (the equivalent
of having locks on your doors and an alarm
system, a first level of defense), but it should
not get commingled with an information-level
security standard. There’s also a place for MAM,
for organizations that need to essentially convert
commercially available computing platforms
into appliances, such as retailers or public safety
organizations. But it too should not get commin-
gled with an information-level security standard.
We don’t need a theory of everything; in fact, it
would assure that nothing ever happens.
What the InfoTrust standard should do
Instead, the information-level security stan-
dard — let’s call it InfoTrust — needs to do the
following:
Provide basic usage rights. Usage rights
need to be embedded in documents, so they
move with the document. Adobe Acrobat is an
example of a file format that support this notion,
and all popular file formats and productivity
apps — Microsoft Office, LibreOffice, OpenOf-
fice, Apple iWork, Google Docs/Drive/Apps, and
so on — need to offer similar usage rights that
transport from one app to another. The rights
should include:
• Restrictions on previewing content
(such as in OS X’s, iOS’s, and Windows’
document-preview capabilities)
• Restrictions on changing content
• Restrictions on copying content
• Restrictions on changing and/or
assigning usage rights and access rights
Enforce basic access rights. It shouldn’t
be an endpoint device’s or app’s responsibility to
control access to content, the approach used by
many MDM and MAM products today. Instead,
the documents should carry the access require-
ments with them, so the apps can validate
access. The requirements should include:
• Password access (as Acrobat and Office
today support)
• Policy access (such as requiring it be in
an encrypted environment or be open
able only by people in a specific Active
Directory group)
Allow local policy management.
Authoring and editing tools should be able to
assign both usage rights and two of the access
rights: the password requirement and the
encryption requirement. That way, small busi-
nesses such as law offices can protect their docu-
ments directly, and trusted employees can share
documents with others outside the corporate
environment (freelancers, contractors, business
partners, governments, and so on).
Apply to all platforms, not just mobile.
Another key principle is that InfoTrust is not a
mobile information security standard. It’s for all
devices: smartphones, tablets, computers, cloud
services, and platform technologies yet to be
invented. Again, it’s not about the device, but
the information, which flows across all sorts of
devices and apps. The device, app, and service are
irrelevant, unless they don’t support the standard.

17. Deep Dive
InfoWorld.com deep dive series 17
Identity
manage-
ment needs
to be done at
the source.
That means
InfoTrust needs
APIs to commu-
nicate with
existing enter-
prise identity
management
tools.
M o b i l e S ec u r i t y
Operating systems, applications, and cloud
services will need to support InfoTrust to act
on the embedded policies in the documents,
just as they need to support EAS today to apply
password and encryption policies. But as a
lingua franca that enables full participation in
the emerging world of anywhere computing, the
key vendors have every reason to participate and
not end up being excluded. The tech industry
has plenty of examples of what happens when
companies delay joining such essential band-
wagons — just ask what used to be Novell or
IBM’s former Lotus group.
Not manage more than is necessary.
Note what’s not included: controls over sharing,
an encryption option, controls over allowed
applications, access management, and identity
management. Sharing controls are not needed
because the documents carry their own permis-
sions; if they are shared (lost, stolen, emailed,
copied to a thumb drive, whatever), the
receiving party has to satisfy the access require-
ments to gain access. It’s the same notion as
trusting that encrypted documents are safe in
today’s privacy-breach regulations. Speaking of
encryption, that means the documents are auto-
matically encrypted, unless they have no access
rights applied.
There’s also no need to worry about what
app or service that users have on whatever
device or computer they’re working with. If
the app doesn’t support the access and policy
requirements, the document can’t be opened
in that app — end of problem. The goal, as my
colleague Terry Retter likes to characterize it, is
the ability to be secure even when operating in
the middle of Times Square.
If a business has other reasons to enforce
the use of specific apps (such as for compliance
logging or to monitor and control distribution of
supersensitive documents), it should use a MAM-
style tool to restrict users to that tool for those
specific documents that need the extra compli-
ance. But there is no reason to burden everyone
for such a subset of use cases.
Today’s MAM and MDM tools are essentially
network-based, requiring a device or app to
check in with a central server to validate and
even enforce its permissions and policies. That’s
not scalable for information management — you
can’t require a server call every time a document
is opened or is acted upon when in use. Yes,
sessions can preserve the policies when offline,
but that’s cumbersome and is of no help when
you’re offline before you open the document.
Network-based validation needs to be required
for only the most critical documents.
Instead, access management has to be
done at the source, so enterprises need to use
tools like SharePoint or any of the many other
information repository systems to control who
gets access in the first place. That doesn’t mean
repository systems need to be the distribution
points, of course — the repository simply needs
to add the permissions to the documents based
on whatever policies IT wants to set using the
policy management tools of their choice. That
way, if a document is emailed, its policy goes
with it. That’s much more secure than today’s
situation, where if anyone gets a document out
of the managed repository, it’s now free and
clear of all policy attributes.
Dozens of vendors who do such policy-based
management tools could adopt InfoTrust. They
could also extend its capabilities in the same way
that Apple’s iOS and OS X use Microsoft EAS
as the basic lingua franca for policy control but
added APIs for more controls that third-party
management tools could choose to enforce. That
gives everyone a sufficient set of information
management capabilities for the vast majority
of their needs and lets vendors layer additional
controls for the truly special ones. That model
works well for EAS across iOS, OS X, Android,
BlackBerry 10, and Windows Phone.
Likewise, identity management needs to be
done at the source. That means InfoTrust needs
APIs to communicate with existing enterprise
identity management tools, such as Active
Directory, to validate user permissions (and even
existence) on documents for which password
security alone is insufficient. Likely, the oper-
ating system will need to provide the local
service that the app communicates with, and
the OS will handle the server communications
— similar to how EAS is implemented today.
The use of documents with server-based identity
protection will require an Internet connection to

18. Deep Dive
InfoWorld.com deep dive series 18M o b i l e S ec u r i t y
validate against the identity management server,
but there’s no way around that reality.
A plea to the tech industry: Make
InfoTrust a reality
I strongly encourage Microsoft, Apple, and
Google — the three platform and app vendors
through which so much business data is acted
on — to get together to develop the InfoTrust
standard. Leading, progressive mobile and
desktop security vendors such as MobileIron,
Good Technology, AirWatch, Centrify, AppCen-
tral, and Apperian should be key players.
Perhaps one or two should even chair the effort
due to their more neutral relationships with the
platform vendors.
Traditional, backward-thinking vendors (such
as those in the antivirus industry) should be
kept at arm’s length, at least in the initial stages.
They’ve shown repeatedly that they can’t get out
of the broken defensive-perimeter trap.
IT keeps saying its security concerns are
about protecting information. So, tech vendors,
stop focusing on straitjacketing devices and
apps and instead protect that valuable informa-
tion wherever it is. n
Galen Gruman is an executive editor at
InfoWorld and its columnist on mobile and
consumerization of IT.
SHUTTERSTOCk/STEPHENSAUER