Mobile Device Security: Whose Data Is It, Anyway?

The argument essentially has two sides. The first side (which I'll call "the company line") argues that corporate data is the property of the company. Based on this notion, it follows that the company can, and indeed must, apply protections to keep sensitive data from being misappropriated or lost—a reasonable argument. The other side (which I've dubbed the "live free or die" crowd) argues that it's inappropriate to apply corporate policy controls to personally owned devices. "It's my phone," goes this argument, "so I should be in control of the policies applied to it."

For the most part, I find myself torn between these two arguments. Each position has many good points. In favor of the company line, we have the following:

• Some data is so critical that losing it can cause measurable financial harm, so it's important for the company to safeguard its data. For this reason, I expect that a big driver of Windows Mobile 6.0 adoption will be its support of Windows Rights Management Services document protection.
• Many organizations want to control which devices or users can access data remotely; for that reason, Microsoft Exchange lets you block devices that don't accept Exchange ActiveSync (EAS) policies, and you can control whether individual users or groups can use EAS.
• Almost every company has policies that govern what employees can do with work computers, and it seems reasonable to extend these policies to mobile devices, which are essentially very small computers.
• If you don't like the idea of having mobile device policies jammed down your throat, you can always choose not to synchronize your personal mobile device with your company's Exchange server.

But the "live free or die" camp has some compelling arguments, too:

• If the company isn't paying for the phone, they have no right to require intrusive policies.
• The current PIN-unlock behavior in Windows Mobile 6.0 and Windows Mobile 5.0 is obnoxious on many devices and applications. Applications such as mapping tools can use a system call to keep the device unlocked while the application is active, but not all applications use this API. Steve Riley, a senior program manager at Microsoft, describes the tension between the need for increased security and the increased risk that comes from having distracted employees trying to unlock their phones while driving, for instance.
• Employees who use mobile devices to be productive on their own time are doing the company a favor, and it's unreasonable to punish them by applying restrictive policies.

As with many other security debates, this one ultimately boils down to a tradeoff between convenience and risk. In organizations where employees buy their own phones, imposing policies can be very unpopular, but it might still be necessary for business reasons. Basic security requirements might dictate that these policies be employed even if their implementation causes extra hassle for end users—after all, most sites use passwords even though they're a hassle sometimes, too.

Ultimately, you should spend some time thinking about the policy approach that makes the most sense for your organization's needs—and that includes your employees' needs, too! If you haven't already deployed mobile devices, this is an ideal time to formulate a policy to avoid unpleasant surprises when you do deploy them. If you already have mobile devices in your environment, you might consider tying policies to device subsidies.

If you've got an innovative approach to dealing with this problem, drop me a line at update@robichaux.net; I'll publish the best solutions in a future column.

End of Article