Unchain your mobile users and just protect the data

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.

[ Galen Gruman describes a smarter approach to mobile security. ]

There are two great models for how this can work. One is Microsoft’s Exchange ActiveSync (EAS) protocol, which provides a de facto standard 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, 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 proprietary 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 commingled 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 standard — 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, OpenOffice, Apple iWork, Quickoffice, 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 requirements 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 openable 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 businesses such as law offices can protect their documents 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.

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 bandwagons — 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 permissions; if they are shared (lost, stolen, emailed, copied to a thumb drive, whatever), the receiving party has to satisfy the access requirements 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 automatically 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 compliance. 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 operating 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 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, AppCentral, 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 information wherever it is.