as good as it is that mothership released msfp, and added in such awesome new functionality…
remote device wipe leaves a lot to be desired.
to be sure, the inability of remote wipe to nuke storage cards makes it nearly impossible to store anything other than utterly insignificant data on said storage cards.
then there’s the issue of the transaction log.
rather than record all the steps of a given wipe permanently, including when the wipe was fully completed…
the transaction log only shows when a wipe, or a wipe cancel, was originally sent. which is totally insufficient as a log of activity, in my opinion
but beyond all that, there’s another huge issue with remote wipe…
ostensibly, remote device wipe should be an answer to a certain fruit-flavored competitor’s remote kill feature.
consider this typical day in the life of a help desk monkey…
wavy lines denoting start of dream sequence
monkey: hello…help desk. how can we, errr…help you?
phb: hey, this is mr. big time ceo talking. i lost my windows mobile device which contains some super-secret info that will cost our company millions of buckaroos. can you do something about that?
monkey: no problem…
monkey sends a remote wipe command while making a suitable sound effect
monkey: bzzzzt! problem solved. the info on that device is hist-o-ree.
phb: fantastic! i’m sending my smoking hot assistant with the keys to my ferrari. go take it for a spin for the rest of the month. and feel free to drive the car as much you want.
wavy lines denoting end of dream sequence
help desk monkey fantasies aside, here’s the reality…
activesync remote administration might not automatically wipe a device
that’s right, you heard me.
remote wipe might leave that device, and any data it holds, totally & utterly compromised.
the very first time any security policy is applied against a device, the device displays the following prompt before applying that security policy.
that is because the device is considered new, as in…it has never had a security policy enforced on it before.
unfortunately, this prompt gives anyone using the device the opportunity to either ignore or cancel the application of that security policy.
and of course, remote device wipe is really nothing more than a security policy being immediately enforced on the device.
now, no additional data synchronization will take place until that security policy is allowed to continue, but that’s not really a problem for someone who just wants access to the data currently existing on a device.
in fact, this kind of loophole is a data thief’s dream…since it effectively means that remote wipe can be countered without any special effort.
there is always the option of configuring password lock with a local wipe option after x number of incorrect password attempts to secure the data on a mobile device.
while your friendly neighborhood happyfunboy is a big advocate of enforcing password lock for mobile devices…
he is not a big advocate of local wipe, simply because it is way too easy for someone to forget their password & simply eat up all their attempts in frustration before they ever call a help desk.
so yours truly spent some time this afternoon in the funlab cooking up a way to close this loophole in remote wipe, with the fruits of this labor being called…
happyfunboy’s super-awesome guide to priming windows mobile 5 for remote device wipe
the secret is to actually apply a security policy to each & every new device that you deploy before you put it in a user’s hands.
once a security policy has been applied & the ok given at the prompt, any subsequent security policy gets applied automatically. which is exactly the kind of behavior you want for a remote wipe command sent to a lost or compromised device.
altho remote wipe itself is a security policy, it completely and utterly reverts a device to an absolute fresh state, so much so that afterwards the device is considered new, from the perspective of security policies. so you can’t simply send a remote wipe command to a device, then set it back up again.
it takes the application of another, non-destructive security policy to actually prime a given device for automatic remote wipe.
luckily, there is just such a non-destructive security policy available in exchange system manager…
altho using the device security options might require you to work out some logistical issues, as we’ll talk about in more depth in a minute…
pushing a password policy will successfully prime a device for auto wiping.
to get started, navigate to & launch exchange system manager
under the top-level organization, expand the Global Settings container, right-click Mobile Services, then click Properties
on the General tab, click the Device Security button
at a minimum, check the Enforce password on device box
if you are going to heed my advice and enable passwords on mobile devices as a general policy, then you can just set this option & let it roll out to all the windows mobile devices without a care in the world, right?
well, besides obviously needing to train the device users on what to expect…
i’d also recommend taking some time to think about enabling other supporting policies that actually make enforcing passwords useful, such as:
minimum password length
if, however, your company is not going to require passwords on mobile devices, then you will want to make liberal use of the Exceptions button.
even if your organization is not going to be enforcing passwords on mobile devices, you can still temporarily set password enforcement to prime a device for auto remote wipe.
however, since setting password enforcement is a global operation…
and as such can affect every device in your exchange organization…
once you’ve primed a device, you’ll want to be sure to add that user to the password exception list, so they don’t inadvertently get prompted to set a password as you toggle password enforcement on & then off.
to set a user as an exception to the password policy…
in Device Security, click the Exceptions button
click the Add button
type the user name in directly, or search the directory for it
once entered/found, click OK on each dialog box to get back to the Mobile Services Properties dialog box, then click Apply
that will keep a device from being caught up by the password enforcement policy unnecessarily.
but let’s get back to what we were doing before…
once the password policy is enabled, either permanently or temporarily…
any mobile device where the user account is not set as an exception will give the same first-timer prompt which requires you to click OK to apply the policy & proceed.
clicking OK again will allow you to update your password settings per the security policy that you set earlier.
wow…you’re presented with yet another chance to click OK. who knew windows mobile 5 could also be used to train you to become a yes man extraordinaire?
you will need to set a password, obviously, & perhaps a bit more depending on the options chosen for the policy.
and if you’re thinking about being cute & setting a blank password…
once the password options are set and accepted, consider the device primed.
obviously, don’t forget to deactivate the password policy once you’re done priming.
after a device has been primed, a remote wipe is initiated nearly as soon as it is sent via the web-based administration tool
just as quickly as an incoming message is received via airsync, really.
first, the screen goes all white very very briefly…
then black for a little while…
then the normal windows mobile splash screen is seen as the devices restarts.
logistically speaking, the ability to prime devices for auto-wipe may depend largely on the size of the environment.
regardless, at this point in time…
without priming, there is no way to reasonably assure that a device in the field will fully execute a remote wipe without leaving a loophole for the data to be compromised.
happy hunting, kiddos