Mobile devices can so easily fall into the wrong hands. I know—I've lost my share of Windows Mobile-based smart-phones and Pocket PC Phone Edition devices. When such a device falls into the wrong hands, so can a lot of corporate information—even the device owner's domain credentials, since most users choose to have the Microsoft ActiveSync client remember their username and password. But help is available in the form of Exchange Server 2003 Service Pack 2 (SP2) and the Messaging and Security Feature Pack (MSFP) for Windows Mobile 5.0.
SP2 and MSFP address some of the fundamental security needs of corporations that use mobile devices by giving you the ability to lock down your far-flung fleet of mobile devices and perform remote wipes. I'll show you how to set up SP2 and configure MSFP on your Exchange server, then walk you through the process of locking down your mobile devices and performing remote wipes on them.
2 Key Abilities
With SP2 and MSFP, you get two new capabilities to help mitigate the security
risk of a lost or stolen mobile device. First, you can lock down devices by
enforcing the use of a device PIN or password to prevent unauthorized access.
You can even configure requirements for the password, such as minimum length
and character composition. To prevent endless guessing of a device's PIN, you
can specify how many consecutive attempts the device should allow before it
wipes all data. Second, upon receiving a report of a lost or stolen device,
you can issue a remote wipe command to the device and have it delete all information.
This centralized control of a few critical functions on mobile devices is similar to the centralized control Group Policy provides over your PCs. These new capabilities are likely just the beginning of centralized device-fleet-management features from Microsoft. (However, if you need sophisticated device-fleet management now, check out Good Technology's product line at http://www.good.com. In my opinion, Good Technology offers the best comprehensive management environment for a heterogeneous mix of mobile devices, and its products far outpace Microsoft's current offerings.)
Although I discuss Windows Mobile devices here (which require MSFP to take advantage of SP2's mobility features), some Exchange ActiveSync (EAS)-compliant devices that don't run Windows Mobile can also carry out remote wipe and password policy instructions from the Exchange server. For example, a growing number of non-Windows Mobile devices—such as Symbian OS-based smartphones and some Sony Ericsson, Motorola, and Nokia phones—use DataViz RoadSync, a third-party EAS client, which supports SP2's Direct Push and remote wipe mobility features.
Installing SP2
I'll assume you already have Exchange Server 2003 SP1 with Outlook Web Access
(OWA) installed. Before installing SP2, you might need to load one or two hotfixes.
If you've installed the security update for Microsoft security bulletin MS05-019
or Windows Server 2003 SP1, you should also install hotfix 898060. If you use
or intend to implement Sender ID, you should also install hotfix 905214. (For
more information about these hotfixes, see the release notes for SP2 at http://download.microsoft.com/download/f/b/5/fb5c54af-fe5c-48e9-be97-f9e8207325ab/ex_2003_sp2_relnotes.htm.)
After you install the necessary hotfixes, it's time to install SP2, which you can download at http://www.microsoft.com/downloads/details.aspx?familyid=535bef85-3096-45f8-aa4360f1f58b3v40&displaylang=en. Microsoft recommends performing a full system backup before installing SP2. Although the installation goes very quickly and doesn't require a reboot, access to Exchange is temporarily interrupted while the services are stopped and restarted, so you'll probably want to do the installation during nonpeak hours.
Lock Down
After installing SP2, you're ready to specify policies regarding PIN or password
usage and lock down your fleet's mobile devices. From the Microsoft Management
Console (MMC) System Manager snap-in, open the properties dialog box for Global
Settings\Mobile Services, which Figure 1 shows.
You'll notice two new elements. The Enable Direct Push over HTTP(s) check box lets you enable or disable Direct Push technology over HTTP or HTTP Secure (HTTPS). Direct Push is a new feature of SP2 and MSFP, and it's Microsoft's answer to Research In Motion's (RIM's) BlackBerry devices, which can receive real-time email updates. However, Direct Push is also important to security, because it lets you immediately reach out to a lost or stolen device and erase your data before a bad guy can exploit it. (I cover the remote-device-wipe feature a little later.)
The other new element is the Device Security button, which, when clicked, displays the Device Security Settings dialog box that Figure 2 shows. To centrally mandate a device password, select the Enforce password on device check box, which activates the other settings and lets you select or clear them depending on your needs.
As Figure 2 shows, I've specified that a device must have a password of at least four characters and that the device be wiped after eight consecutive failed attempts to enter the password. The device will lock after a five-minute period of inactivity.
Be reasonable with the requirements you configure in Device Security Settings. Remember that users need quick access to their devices—if you're too strict, you'll foster uncooperative users. If your users' devices are also mobile phones, they'll be happy to know that with most devices, as far as I know, users can answer incoming calls without first unlocking the device. However, the device remains locked during the call until the user enters a password. Also, regardless of the physical buttons on the device, Windows Mobile 5.0 displays an on-screen numeric keypad when prompting for a PIN. Many organizations will determine that a four-digit PIN is sufficient to guard the device, provided it's configured to wipe after a reasonable number of failed attempts. I believe a four-digit PIN combined with automatic wipe provides the right balance of security and usability.
If you support devices that aren't enabled for MSFP, you need to select the Allow access to devices that do not fully support password settings check box to apply the settings to all devices in your fleet. Since there are always special situations, Exchange also lets you specify exceptions. When you click Exceptions, Exchange System Manager (ESM) displays the Device Security Exception List dialog box that Figure 3 shows. Here you can add users whose devices are exempt from the requirements configured in the Device Security Settings dialog box. You make exceptions for users, not specific devices; for example, if an exempt user has two devices, both devices will be made exempt.
Remote Wipe
After installing SP2, you need to install the Exchange Server ActiveSync Web Administration tool before you can use the remote wipe feature. The Web Administration tool is a browser-based tool that provides the remote administration and remote wipe feature for all mobile devices running Windows Mobile 5.0 and MSFP, as well as any device that supports third-party EAS clients. You can download the tool at http://www.microsoft.com/downloads/details.aspx?familyid=e685 1d23-d145-4dbf-a2cc-e0b4c6301453&displaylang=en.
When you open the downloaded file, it prompts you for a folder to which to extract files. After extraction, open the folder and double-click MobileAdmin.msi to create a new folder called MobileAdmin under the server's default Web site. To access the Web Administration tool, open a browser and enter
https://mail/mobileadmin
where mail is the name of your Exchange server.
After authenticating, you'll see the Mobile Device Settings page of the Mobile Admin Web Form, which Figure 4 shows. Click Remote Wipe to display the Remote Device Wipe page similar to that which Figure 5 shows. To find a device, you must enter the mailbox name or SMTP address of a user who synchronizes with Exchange from one or more devices. EAS tracks each device from which a user synchronizes, and the Mobile Admin Form uses this information to display a list of devices associated with the specified mailbox.
As the Remote Device Wipe page shows, a Pocket PC is associated with my account. The page displays the date and time of the last synchronization and offers two actions: Wipe and Delete. If I click Delete, Mobile Admin clears the association between the Pocket PC and my account. If I subsequently synchronize again using that device, EAS will re-create the association. The Delete feature lets you perform housekeeping when a device is no longer used.
Let's say my Pocket PC has been stolen. When I click Wipe, the tool issues a remote wipe command to the Pocket PC. Figure 6 shows the status of my Pocket PC after I initiate a wipe. If the device is currently on and connected via the long-lived HTTP connection (a port 443 TCP connection that doesn't time out) used by MSFP's Direct Push technology, the device will erase all its data within seconds. Otherwise, the wipe won't take effect until the next time the device connects to the Exchange server.
For what it's worth, I tried issuing a remote wipe command to a Pocket PC that didn't have MSFP loaded. The device didn't wipe its data, of course, but the synchronization did fail and issued support code 0x85010013. So, although devices that aren't MSFP-enabled can't carry out remote wipe commands, you can at least disable continued synchronization for that device if you lose control of it.
The Web Administration tool tracks the status of the remote wipe command, so that you can return to the Remote Device Wipe screen and check for completion of the command. If the user recovers the device before the wipe command is carried out, you can cancel the command by returning to the Remote Device Wipe page and clicking Cancel Wipe.
Caveats
There's no guarantee that your Windows Mobile device will support remote wipe or a centrally mandated password policy because those features are part of the optional MSFP. Support for MSFP depends on the device manufacturer—and sometimes on the carrier. Before buying a Windows Mobile device, make sure it comes with MSFP or that the feature pack is available from the carrier or manufacturer. (Microsoft offers a buyer's guide of Windows Mobile 5.0 devices at http://www.microsoft.com/windowsmobile/devices/default.mspx.)
EAS support in mobile devices isn't limited to Windows Mobile devices. Manufacturers such as Nokia and Motorola and ISVs have licensed EAS, and DataViz makes EAS clients for a variety of phones based on Palm OS, Symbian, and Java Mobile Information Device Profile (MIDP). Before you buy, read the specifications or manual to make sure you understand whether the third-party EAS-compliant device or client software you're considering supports remote wipe and mandated password policy. Also, be aware that some devices that support HTTPS-protected EAS and Direct Push are limited to a finite Certification Authority (CA), which means the device refuses to connect to your Exchange server unless you purchase a digital security certificate from one of the commercial CAs that the device supports, such as VeriSign or its subsidiary, thawte.
Some mobile devices let you store email attachments on a removable flash memory card to conserve internal memory. Doing so carries a big risk, however, because attackers can easily remove Secure Digital (SD) and other such memory cards—possibly before theft is reported or before your remote wipe command is carried out. Moreover, some of your organization's most sensitive data is likely to be found in attachments. EAS with MSFP is apparently supposed to disable the ability to store attachments on the device's removable storage, but if you want to use that feature, I recommend testing specific devices and software to make sure it works correctly.
A Good Step Forward
How secure does MSFP make the data and credentials on your mobile devices? Some analysts, such as Gartner, complain that Microsoft hasn't done enough with encryption to combat more sophisticated attackers who crack open a device and attempt to extract data from its memory. The Trusted Computing Group's Mobile Phone Work Group subgroup is working on mobile-device security, and I expect mobile devices to become more secure in the future. (For more information, see https://www.trustedcomputinggroup.org/groups/mobile.)
If your biggest concern is the theft of user domain credentials, you might consider implementing client certificates to control access to EAS. Enrolling Windows Mobile devices for client certificates is much easier than in the past, thanks to the new Enroller application on the device Start menu, which lets you request a client certificate from your Windows Server CA. At some point, we'll probably see biometric access controls on devices, and tamper-proof chips that contain an encryption key will protect data. For the time being, however, SP2 and MSFP take you a good step forward in mitigating the biggest risks associated with mobile devices.
