Don't fire people until after you wipe their phones

A very commonly required feature for mobile access to email is remote wipe - the ability to reach out and wipe all corporate data off a mobile device. Exchange ActiveSync supports this feature and has for several versions now. You, as the Exchange or Security administrator can issue a remote wipe command to a compliant device, or the user can do it themselves through Exchange, and the next time the user connects the device will be wiped.

There are two major flaws in that design. One is the well understood "the next time the user connects" part: you cannot reach out to the device and immediately wipe it. The devices do support receiving remote commands through SMS, but for some reason there is no function in Exchange to use that feature to somehow, securely, trigger a remote wipe.

It turns out, however, that there is another, possibly even larger, flaw in the implementation of remote wiping in Exchange ActiveSync. Here is the work flow:

  1. Device connects to Exchange Server
  2. Device transmits DeviceID
  3. Exchange server asks for authentication
  4. Device authenticates
  5. Exchange server checks if a remote wipe command has been issued for the device
  6. ...

Spot the flaw yet? Consider this scenario

  1. Bob failed to sufficiently internalize the sexual harassment training and racks up enough points to get fired
  2. Bob is walked to the door with his shiny personal Windows Phone 7 Smartphone or whatever in his pocket
  3. IT Department is notified that Bob has been terminated and disables/deletes his account
  4. IT Department, following the security policy, issues a remote wipe command to Bob's phone

Pop quiz: What happens to all the company confidential data on Bob's device?

Answer: Nothing! It will stay there for as long as Bob decides it should. Go back and look at the connection workflow again. The Exchange server will only send the remote wipe command to Bob's device after Bob has already authenticated. The IT Department did the absolutely logical thing and disabled Bob's account. Therefore, he will never successfully authenticate again. The way remote wipe is implemented in Exchange ActiveSync means we just lost the ability to wipe our data off Bob's mobile phone.

The alleged solution to this is that you should reverse steps 3 and 4 in your firing process: leave Bob's account active until his device gets wiped. If that makes you just a little queasy you are not alone. In my opinion, this is a major feature miss. Remote wipe in Exchange ActiveSync is only useful when a user loses his or her device, and even then, it is lacking since you cannot reach out to the device and wipe it. Remote wipe in Exchange ActiveSync is utterly useless when people are terminated from their employer.

Published Thu, Apr 8 2010 8:31 PM by jesper
Filed under: , ,

Comments

# Mick Huxley said on 09 April, 2010 12:06 AM

Jesper.. Let me preface my comments by stating that I couldn't find any detailed information about the "Logon To" AD account setting and can only *assume* that it applies only to Interactive Logons and not Network Logons.  ActiveSync is a Type 3 Network Logon

If this is the case then simply leaving the account enabled and setting a non-existent host as the only "log on to" workstation would work around this issues.  Worst case if "Log on to" covers all logons then I may need to add my CAS Server and MB server also.  Therefore I can restrict the user to simply a network logon initially whilst I wait for the device wipe to occur.

Monitoring the users mailbox I can see when the confirmation email of the wipe is received and then disable the account.  With Hub Transports rules I could even capture these messages and add an alternate recipient.

Whilst this isn’t an ideal solution it does mean that our offending employee will need to get onto the Corpnet, with another device or get someone with Interactive Logon rights to assist, before any damage can be done.  Removing all groups the users is a member of will lock this down further also.

# Alun Jones said on 09 April, 2010 04:37 PM

I was going to suggest something similar to Jesper, until I realised that pretty much said "OK, so you have to keep the account active, here's how to deactivate one of several ways that account could be used while still active". Depending on how easily accessible the other ways are, that could be good, bad, or indifferent.

As a f'rinstance, let's suppose you have a wireless that authenticates through RADIUS, your disgruntled employee could take a wireless-equipped personal laptop to the coffee bar downstairs in the public area of your building, log on, and start tromping through the network filespace without trying to present an interactive logon.

# Dale said on 11 April, 2010 04:50 PM

BlackBerry devices suffer from the same "next time a user connects" problem.  If the user has pulled the SIM card out of his device, then we can't send it a wipe command.

Wondering out loud:

"Maybe a ticket based approach is the way to go.  The device is issued a ticket, with an expiry date, by the mail server.  If the device fails to renew the ticket by the expiry date, the device is wiped.  That would solve the 'not on the air problem'."

The flaw would be if you had a mail server outage, which then prevented tickets being renewed.  

# Mick Huxley said on 13 April, 2010 07:45 PM

Alun.. good point about the RADIUS auth for Wireless.  Another suggestion maybe to create an AD Group called disabled users.  Add the user to this group, make it the primary group and remove them from Domain Users.  Then simply ensure that the use of "Everyone" or "Authenicated Users" is tightly controlled.

# Kathi said on 10 June, 2010 05:00 AM

To Jesper:

well i was wondering if you have been travelling recently? I might have seen you but Im not quite sure. I wanted to mail you but i lost track of your email adress. I feel sorry bothering you here but i couldnt find an other alternative.