Infoworld Mobile Security Deepdive

MOBILE

SECURITYTTYTY

i O S

VS. A N D R

O I D

VS. B L AC

K B E RR Y

VS. W I N D

OW S

P H O NE

DeepDiveC

OP

YR

IGH

T

20

15

IN

FOW

OR

LD M

ED

IA G

RO

UP.

ALL

RIG

HT

S R

ES

ER

VE

D.

ST

EP

HE

N S

AU

ER

Deep Dive

InfoWorld.com DEEP DIVE SERIES 2PA A S

iOS vs. Android vs. BlackBerry vs. Windows Phone

Deep Dive

2InfoWorld.com M O B I L E S EC U R IT Y

Googles Android for Work and Samsungs Knox promise serious security, but how do they stack up against Apples iOS and the rest? BY GALEN GRUMAN

Mobile

secu

rity

Deep Dive

InfoWorld.com DEEP DIVE SERIES 3PA A S

Apples iPhone and iPad long ago pushed out the BlackBerry as the corporate standard for mobile devices, in all but the highest-security environments. Google whose Android plat-form reigns outside the corporate world is now trying to push out Apple, with a new effort called Android for Work. And Samsung is upping the game with a new version of its own Android security suite, Knox.

What Android for Work does and doesnt doThat technology came to market last week, adding new security and management capabili-ties, 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 workspace on your device are part of the Android 5 Lollipop OS and support any Google Play store apps. But Android 3.0 Ice Cream Sandwich through 4.4 KitKat requires 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 new Android 5.0 Lollipop would enable encryption by default on all new devices. (Upgraded devices encryption state is unchanged.) But theres no requirement that the devices use a crypto chip, so users could see major performance hits. InfoWorlds sister publication Greenbot found that Googles 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.

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

Deep Dive

M O B I L E S EC U R IT Y InfoWorld.com DEEP DIVE SERIES 3

Get More Mobile Thought Leaderships Samsung Knox 2.4 vs. Google Android for Works How to rethink security for the new world of ITs Real data security for all is now getting its start on mobiles Mobile and PC management: The tough but unstoppable unions Mobile management: Making sense of your optionss Unchain your mobile users and just protect the datas Liquid computing: The next wave of the mobile experiencesConsumerization of IT: How IT should manage personal technology at work

Deep Dive

4M O B I L E S EC U R IT Y InfoWorld.com DEEP DIVE SERIES

first version of Microsofts mobile platform to support device encryption.)

Knox aims for corporate-issued Android usersAnnounced two years ago, Samsungs Knox has had a difficult rollout and now has Googles 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 stabilizedGoogles Android for Work move comes 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 dont 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.

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 focusedThese days, the mobile management vendors focus is on content and application security since device management is all but settled. Apples 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 Apples management and security into new areas, including application management and licensing management. The recent iOS 8 has only a few additions.

Apples 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 cant install a personal copy free of restrictions and a business copy managed by IT.

Apple didnt invent the API-managed apps notion; in 2011 several startups offered mobile application management technology that required app developers to implement proprietary APIs and proprietary management tools. They went nowhere. Apples 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

Apples 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.

Deep Dive

5M O B I L E S EC U R IT Y InfoWorld.com DEEP DIVE SERIES

Policy

AppleIOS 7, 8

GoogleANDROID 4, 5

SamsungANDROID 5 + KNOX

BlackBerryBLACKBERRY 10

MicrosoftWINDOWS 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 MDMYES NO

Require signed S/MIME messages

YES NO MDM MDM YES [2]

Require encrypted S/MIME messages

YES NO MDMMDM YES [2]

Require signed S/MIME algorithm


Require encrypted S/MIME algorithm

YES NO MDMMDM YES [2]

Allow S/MIME encrypted algorithm negotiation


Allow S/MIME soft certs NO NO YES MDM YES [2]

EXCHANGE ACTIVESYNC (EAS) POLICY SUPPORT COMPARED

( M D M M E A N S A S E PA R AT E M O B I L E D E V I C E M A N A G E M E N T S E R V E R I S R E Q U I R E D )

[1] Storage areas only. [2] Windows Phone 8.1 only.

Deep Dive

InfoWorld.com DEEP DIVE SERIES 6M O B I L E S EC U R IT Y

work on, into a separate workspace not acces-sible by the users 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 vendors mobile management server. Thus, theyve 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 Black-Berry Balance, the first platform-level contain-erization approach, for BlackBerry 10 devices. It also has a Balance container app, called Secure Work Space, for iOS and Android.

Last spring, Google purchased containeriza-tion vendor Divide and later said it would make containerization part of Android now the Android for Work technology that became avail-able last week.

Container policies differ widely from container to container, which can make manage-ment difficult. However, now that popular mobile management servers support both iOSs APIs and Androids 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 BlackBerrys 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, its a mess.

Native security and management API capabilities comparedAs 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.

iOSs 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 search. iOS 8 supports per-message S/MIME and both IKEv2 and always-on VPNs, as well.

Android API tour. Although Google hasnt 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

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.

Deep Dive

InfoWorld.com DEEP DIVE SERIES 7M O B I L E S EC U R IT Y

CapabilityAppleIOS 7, 8

GoogleANDROID 4, 5

SamsungANDROID 5 + KNOX 2.4

BlackBerryBLACKBERRY 10 BES12

MicrosoftWINDOWS 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]

OTHER NATIVE MANAGEMENT CAPABILITIES COMPARED

( T Y P I C A L LY R E Q U I R E S A M O B I L E D E V I C E M A N A G E M E N T S E R V E R T O U S E )

cant 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.

Google also says the Google Play app store can now provision apps to Android devices through volume business licenses, similar to Apples 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

[1] Added by some smartphone makers. [2] In Windows Phone 8.1 only (and VPN support is partial). [3] In secured container only.

Deep Dive

InfoWorld.com DEEP DIVE SERIES 8

Its a no-brainer that iOS and BlackBerry OS have what it takes for almost any businesss security needs.

M O B I L E S EC U R IT Y

use a SAFE-compatible device and management server to use those extra policies. The SAFE APIs have been replaced with the 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 tools 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 managementNo 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 for example, managing email forwards are handled outside the OS by MDM client apps such as MobileIrons.

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 its 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.

Its a no-brainer that iOS and BlackBerry OS have what it takes for almost any businesss security needs. Android, especially with Android for Work or Knox 2.4 in use, is a plausible plat-form 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 appro-priate for midlevel security requirements. Q

Galen Gruman is an executive editor at InfoWorld and its columnist on mobile and consumerization of IT.

Deep Dive

InfoWorld.com DEEP DIVE SERIES 9

Mobile and PC management: The tough but unstoppable union


One day, youll manage all client devices from a central

policy console, but it wont be a fast or easy journey

BY GALEN GRUMAN

You know that a trend has peaked when the establishment jumps on board. Thats 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 dont.

ST

EP

HE

N S

AU

ER

Deep Dive

InfoWorld.com DEEP DIVE SERIES 1 0

Thats why MDM is shi!ing away from mobile to encompass anything and everything a user might access: smart-phones, tablets, computers, even cloud desktop services.


Thats 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 othersWhat 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 couldnt 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 BlackBerrys 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. Its an approach that CAs 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 dont have a connec-tion, so you dont 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, dont leave the trusted network, and in fact are treated as an attached node, not an occasional guest. Thats 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 hasnt used the domain-join approach in Windows Phone and Windows RT. The domain join for PCs implied a context for environment, says Dells Foster, but more and more, PCs are not connected via a domain, so that context is gone.

Its telling that Microsoft doesnt 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. Microsofts Windows OS team declined to speak to InfoWorld about its views on management, and the server group didnt want to speak for the OS group. But with Windows 8.1, its 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,

Deep Dive


Most companies dont manage desktop and mobile from the same team.RAM VARADARAJAN, GENERAL MANAGER AT CA


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 its 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 dont 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. Were not

seeing a propensity to go to one management system in one shot, but as a phased evolution, says Dells 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 Microsofts 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. Were seeing a trend toward more unified management, notes Microsofts Conway. Most corporations dont want this island of mobile any more; they want to treat it all as one, says CAs Varadarajan.

But until they unify the IT teams, a unified tool doesnt 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 youre 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 theres 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

Deep Dive


Hoping to impose a common set of devices, appli-cations, and services is a pipe dream. But that doesnt mean IT shouldnt seek unity.


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 Phones big differences with PC Windows.

Of course, some policies simply dont apply to some devices, but a unified tool would know that and would ignore irrelevant policies while flagging policies that are relevant but cant be deployed to a specific device. A crude example of that is Apples 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 isnt 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 its 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 Microsofts 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 Microsofts PC OS down the path that Apple began with OS X Lion: using APIs for mobile-style payload-based management.

Dells 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 customers specific needs. Were finding that customers are all very

different, so theres a lot of custom work, la professional services, says Dells 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 CAs Varadarajan.

Cloud storage is a great example of that notion, says Dells 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. Thats 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 doesnt mean IT shouldnt 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. Q


Deep Dive

InfoWorld.com DEEP DIVE SERIES 1 3M O B I L E S EC U R IT 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, whove been doing so for years on the desktop.

Its 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 cant use and forcing the use of proprietary app containers that cant scale

a heterogeneous, interconnected digital environment or that provide read-only

access (whats the point, then, of having the file?). Instead, its 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 Microsofts 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 ITs 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,

Unchain y

our

mobile us

ers

and just p

rotect

the data

IT and the security industry are both focused on dubious protection plans. This proposed standard shows a better wayBY GALEN GRUMAN

Deep Dive


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.


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, dont 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 todays mobile device management (MDM) and mobile application management (MAM) tools cant 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. Its a good suggestion, but it should not be limited to mobile and it needs to work like the Wi-Fi Alliance in that it doesnt 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. Theres 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. Theres 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 dont 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 lets 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:

sRestrictions on previewing content (such as in OS Xs, iOSs, and Windows document-preview capabilities)sRestrictions on changing contentsRestrictions on copying contentsRestrictions on changing and/or assigning usage rights and access rights

Enforce basic access rights. It shouldnt be an endpoint devices or apps 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:

sPassword access (as Acrobat and Office today support)sPolicy 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. Its for all devices: smartphones, tablets, computers, cloud services, and platform technologies yet to be invented. Again, its 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 dont support the standard.

Deep Dive


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.


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 IBMs former Lotus group.

Not manage more than is necessary. Note whats 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. Its the same notion as trusting that encrypted documents are safe in todays privacy-breach regulations. Speaking of encryption, that means the documents are auto-matically encrypted, unless they have no access rights applied.

Theres also no need to worry about what app or service that users have on whatever device or computer theyre working with. If the app doesnt support the access and policy requirements, the document cant 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.

Todays 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. Thats

not scalable for information management you cant 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 thats cumbersome and is of no help when youre 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 doesnt 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. Thats much more secure than todays situation, where if anyone gets a document out of the managed repository, its 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 Apples 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

Deep Dive

InfoWorld.com DEEP DIVE SERIES 1 6M O B I L E S EC U R IT Y

validate against the identity management server, but theres 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 arms length, at least in the initial stages. Theyve shown repeatedly that they cant 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. Q


SH

UT

TE

RS

TO

CK

/ S

TE

PH

EN

SA

UE

R

Documents

Infoworld Mobile Security Deepdive