I’ve been writing about many different enterprise mobility management solutions recently, and one of the questions that comes up is how they handle security for email and attachments. Today I’m going to outline the three most common techniques.
For a baseline, we’re going to assume that IT will not only want to protect email with basic security policies like passwords and encryption, but also keep third-party apps from accessing and leaking data as well. I’m using the term enterprise mobility management as a way to collectively describe vendors that do mobile device management, mobile application management, and address bring your own device. It will be clear in each of the following scenarios where MDM comes into play and where MAM is used. Let’s dive in!
1. Protect the whole device
The simplest way to protect email on a mobile devices is to actual manage and secure the entire device. Users sync their Exchange accounts to their device’s native built-in email client and then MDM is used to enforce password protection, encryption, remote wiping, and other security features. The email client is protected because the whole device is protected.
But that’s only half of the problem. The other half is that the built-in email clients in iOS and Android are designed to share calendars, contacts, and attachments with any random third-party apps that happen to be on the device. This is convenient for users, but it also means that corporate data can easily be leaked. The only way to stop this is to control what applications are installed on the device in the first place using MDM blacklisting capabilities. (This isn’t always a smooth process, but that’s another whole discussion...) In most situations you’ll probably only block especially dangerous apps or apps that are confirmed malware, but depending on your environment, the amount of blacklisting can range anywhere from totally locked down to wide open.
The good thing about this tactic is that you don’t need any special tools beyond just basic MDM. (Though you’ll probably need some sort of resource like Appthority to help you decide which apps are actually threatening). The downside is that users will be upset if you deem one of their favorite apps to be dangerous and block it, especially if it’s a personal device.
2. Middle of the road: encrypted attachments
If all you’re really worried about are the email attachments, then you can intercept them before they get to the device and encrypt them. Once on the device, only managed corporate apps can decrypt the attachments, not personal apps. You can still use device-level MDM to put some basic security on the device (and thus also the email client), but you don’t have to be nearly as concerned about what random apps the user has installed. The actual email messages, contacts, and calendar are still exposed to the user’s apps, but a lot of the time this is okay, since the attachments are still protected.
The major leap here is that you have to be doing some sort of mobile app management in order to have the corporate apps that can decrypt the attachments, but you can start with just a file syncing client with a built-in document viewer and add other corporate apps to the ecosystem as you get to them.
What’s good about this middle of the road approach is that users get to use the native built-in email client, but IT still gets to control what apps have access to attachments. The disadvantage is that you’ll have to be deploying some corporate-managed apps in order for attachments to be useful.
Right now only a small handful of EMM vendors support this scenario, including MobileIron, AppSense MobileNow, and AirWatch.
3. Third party email apps
The final option ignores the built-in email client in favor of a third-party client app. This means that IT can have complete control over all aspects of email. Security policies are applied directly to the app itself, and only other corporate-managed apps will be able to access attachments and other data, per IT policy.
The advantage with a third party app is that IT doesn’t have to be concerned at all with what’s going on at the device level, and yet they still full control over email. The problem with third-party email apps is that they may not have the same look and feel as native built-in clients, and some users also dislike not being able to view their personal and work email in the same app.
Most solutions rely on Exchange ActiveSync device access rules to restrict access to just the 3rd party client app and not the built-in one, though some like Good Technology use a proprietary protocol. While there are dozens of manageable email client apps out there, not all EMM vendors provide one of their own.
Which do you pick?
Which of these techniques is best? None of them? All of them? The reality is that each one of these techniques involves some sort of a trade-off, whether it’s using a third party app or dealing with app-blacklisting. We’re asking for more protection than mobile devices provide on their own, and it doesn’t come without a penalty in some way or another. Different EMM vendors will skew different ways on this, too. Your environment might push you towards one option or another, but by providing users with multiple options and allowing them to pick on their own you can keep a lot more of them happy.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.