Exchange ActiveSync Remote Device Wipe

As mobile devices get smarter, people increasingly rely on them as an adjunct to their work computer. This change is having many effects, both obvious and subtle, on the computing and work landscapes. For example, Microsoft's "three screens and a cloud" strategy puts smart mobile devices on a par with laptops and desktops.

However, mobile devices have a couple of unique disadvantages compared to other work-oriented computing devices. First, they're small, and thus easy to lose. For a great example of this hazard in action, look no further than the recent story of an Apple engineer who misplaced his prototype iPhone and became internationally, and unintentionally, famous. Second, they're often personally owned, not corporate property. This situation naturally changes employee expectations about privacy and security. In particular, personally owned devices often mingle company-owned—and possibly sensitive—information with personal data. The trend toward seamlessly integrating data from social networks and business services is accelerating, as we've seen from the previews of Facebook and Twitter integration in Windows Phone 7 and iPhone 4.0.

Microsoft Exchange Server attempts to deal with these situations by providing policy controls that let IT departments control which devices can connect to Exchange and what device features can be used on synchronized devices. For example, you can set up an Exchange ActiveSync (EAS) policy that allows only certain types of devices to connect, or permits only certain users to use EAS. However, it seems that many companies aren't making use of these controls, either because they're not aware of them or because they prefer to let employees self-provision phones, connect them with EAS, and get about their business. Instead, organizations of all sizes are relying on EAS's remote wipe mechanism to protect them.

The current implementation of EAS remote wipe poses some challenges, though. First of all, when an administrator or user requests a remote device wipe, the device won't get the wipe command until the next time it syncs. This seems obvious, and in general, it's not a huge obstacle because smart devices are intended to be always-on. If you've protected your devices with a PIN lock, an attacker who gets a device won't be able to unlock it to turn off syncing.

There's a more subtle problem, though: What about employees who have been fired or laid off? The wipe command won't arrive at the device until its first successful sync after the wipe command is issued. That means that the account credentials on the device must be valid to sync. What happens if you disable an employee's account or change the account password as part of the termination? You guessed it: That employee's device no longer has valid credentials, so it won't sync, so it won't be remotely wiped. Although a device in this state won't get any new data, it might still have valuable or sensitive company data on it.

One way to fix this problem would be to allow EAS devices to make unauthenticated connections to pick up wipe commands. There are drawbacks to this approach too, not least of which is that it still requires a device sync, so an attacker or former employee who turns off the device radio can still have access to the data.

Another potential fix is to have the device wipe itself unless it receives a keep-alive message (over an authenticated connection) telling it not to do so. The problems with this method are pretty obvious, too: Turn off your phone for too long—say, while you're on vacation or hiking—and boom! No data.

Another related problem: The existing remote wipe implementations on all EAS devices that I'm familiar with erase everything on the device, not just the data synced from the Exchange server. That means that wiping a former employee's phone kills everything from your secret project plans to the employee's personal phone numbers and grocery lists. It would be great to see EAS implementers get more selective about which data types should be erased, although this would probably require an extension to the EAS protocol to define two types of wipe: complete erasure and erasure of only those data items that came from the Exchange server in the first place.

The remote wipe situation is a complicated problem to solve properly because it has implications for privacy, security, usability, liability, and device manageability. I look forward to seeing how Microsoft and its ecosystem partners will tackle it—because it is important.