Don't be so trigger-happy for a remote wipe

IT often feels better knowing it can wipe a user's device at will, but there's usually a more sensible option

When I talk to IT pros about the proliferation of user technology, aka consumerization, it doesn't take long before the subject of remote wipe comes up. It's become almost a checklist item in any company that supports BYOD and increasingly for those who supply mobile devices. After all, regardless of who buys the device, it may contain corporate secrets that need to be kept away from prying eyes. As OS X Lion and Windows 8 bring remote-wipe capabilities to desktop computers, I'm sure we'll see IT begin to apply it to employees' home and work PCs as well.

But too many in IT are overly eager to pull the remote-wipe trigger. It's a serious weapon, the equivalent of a neutron bomb being set off in an iPad, iPhone, Android device, Mac, or -- with third-party tools today and a new OS this fall -- Windows PC. Like any tool with such overwhelming capabilities, it should be used with caution.

[ Understand how to both manage and benefit from the consumerization of IT with InfoWorld's "Consumerization Digital Spotlight" PDF special report. | Subscribe to InfoWorld's Consumerization of IT newsletter today, then join our #CoIT discussion group at LinkedIn. ]

As a cautionary tale, consider what happened to Mimecast CEO Peter Bauer, as related by my Network World colleague Colin Neagle: When on vacation, his young daughter tried to use his iPhone but didn't know its password. After several failed log-in attempts, the iPhone wiped itself, per the BYOD policies Bauer himself put in place and that his mobile device management (MDM) tool applied. Poof! Gone were all the vacation photos for that trip, as they had not been backed up -- nor could they have been -- to his computer back home. Apple's iCloud service would have saved his photos, but only if he enabled it and had Wi-Fi access or was willing to eat into his data plan for cellular backup -- and if his MDM policies didn't block its use.

It didn't have to be that way.

Exchange Server doesn't provide much flexibility in its remote-wipe settings for iPhones, iPads, and supported Android devices: It's on or off, and all you can specify is the number of failed log-in atempts needed to trigger a complete device wipe. But third-party MDM tools give you the ability to wipe just corporate data (coming from your servers, not the users' data) based on a failed log-in threshold that you set.

Your first line of defense should be requiring a strong-enough password, on-device encryption, and a low autolock time (a few minutes) for both mobile devices and PCs. You want a device locked with a password complex enough to not be easily guessed, but not so complex it will be hard to enter or so hard to remember it gets taped to the back of the device or to the PC monitor's bezel or keyboard tray.

A locked and encrypted device will be protected from most prying eyes. A lock also buys time for the user to find the smartphone or tablet, should it be misplaced; chances are it's under a cushion, a chair, or another innocuous location. If you jump to a "wipe when called" policy, your users simply won't call until it's been missing a few days. It's better to issue a more stringent lock to the device instead, which some MDM tools can do, as can Apple's iCloud service and -- for IT's use -- OS X Server for both Macs and iOS devices. Microsoft's System Center has similar capabilities for Windows, and a variety of security vendors such as F-Secure and Symantec offer related capabilities for several mobile and desktop platforms, such as Android.

The point is that for most organizations, there are several security options available before you come to a complete device wipe. Start with them before you set off the neutron bomb.

This article, "Don't be so trigger-happy for a remote wipe," was originally published at InfoWorld.com. Read more of Galen Gruman's Smart User blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Copyright © 2012 IDG Communications, Inc.