Over the years, I’ve attended various presentations featuring mobile access to data but most of them have been along the lines of “look at all this cool stuff I can do”. Last week I was at the Microsoft IT Security Summit and saw a slightly different angle on things as Jason Langridge presented a session on securing Windows Mobile devices – something which is becoming ever more important as we increasingly use mobile devices to access data on the move.

It’s surprising just how few people make any effort to secure their device and, according to Microsoft, only 25% of mobile users set even a password/PIN. Even so, that’s just the tip of the iceberg – mobile data exists in a variety of locations (including paper!) and whilst many IT Managers are concerned about data on smartphones, PDAs and USB devices, paradoxically, many notebook PCs have an unencrypted hard disk containing many gigabytes of data. A mobile security policy is different to a laptop security policy – and it’s more than just a set of technology recommendations – it should involve assessing the risk and deciding what data can safely be lost and what can’t. Ultimately there is a fundamental trade-off between security, usability and cost.

Potential mobile device security threats can come from a number of sources, including malware from applications of unknown origin, viruses, loss/theft, unauthorised access via a personal area network, wireless LAN, wireless WAN, LAN or through synchronisation with a desktop/notebook PC. Each of these represents a subsequent risk to a corporate network.

The Windows Mobile platform supports secure device configuration through 43 configuration service providers (CSPs). Each CSP is an XML document that can be used to lock down a device, for example to disable Bluetooth:

The diagram below illustrates the various methods of provisioning and control for mobile devices, from direct application installation or desktop ActiveSync, through in-ROM configuration to over-the-air provisioning from Exchange Server, WAP or the Open Mobile Alliance (OMA) industry standard for mobile device management.

The most secure method of configuring a mobile device is via a custom in-ROM configuration – i.e. hard-coded XML in ROM, run during every cold boot. This method needs to be configured by the OEM or system integrator who creates the device image.

Secure system updates provide for after-market updates to device configuration, even when mobile. Image updates (a new feature for Windows Mobile 5.0) can update system files ranging from the full image to a single file including handling dependency and conflict resolution. Controlled by the OEM or the mobile operator, image update packages are secured using cryptographic signatures.

Probably the simplest way to provide some form of perimeter security is using a PIN code or strong password (depending on the device), incorporating an exponential delay with each incorrect password. Such arrangements can now be enforced using the tools provided in Exchange Server 2003 SP2 and/or the Systems Management Server device management feature pack. Taking a look at Exchange Server 2003 SP2, it not only delivers improved access to Outlook data when mobile with reduced bandwidth usage and latency, direct push e-mail, additional Outlook properties and global address list lookup; but it also provides security policy provisioning for devices with password restrictions, certificate authentication, S/MIME and the ability to locally or remotely reset a mobile device.

Windows Mobile does not encrypt data on devices due to the impact on performance; however it does include a cryptographic API and SQL CE/SQL Mobile access provides 128-bit encryption. If data encryption on the device is required (bearing in mind that the volume of data involved is small and the observation that many notebook PCs representing a far larger security risk are unsecured) then third party solutions are available.

Mobile applications can be secured for both installation and execution. For installation, the .CAB file containing the application can be signed and is validated against certificates in the device certificate store. Similarly, .EXE/.DLL files (and .CPL files, which are a special .DLL) need to be signed and validated for execution. Users are asked to consent to install or execute signed code, and if consent is given, a hash of each file is added to a prompt exclusion list to avoid repeated prompts. Copying executable files to the device is not the same as installing them and will result in an execution prompt.

Windows Mobile includes a two-tier application execution control with the 1-tier mode including either blocking execution completely or running as privileged/trusted. If 2-tier mode is in use, an application could be signed for one of two different trust levels – either privileged, with access to registries, APIs and hardware interfaces; or unprivileged, with applications restricted from certain operations. Smartphones support 1- or 2-tier operation; whereas PocketPC devices are limited to a single tier.

Whilst application installation security can provide good protection against viruses and other malware, there are also anti-virus APIs built in to Windows Mobile with solutions available from a variety of vendors.

As new wireless network technologies come onstream, it is important to consider wide area network security too. Windows Mobile supports NTLM v2 as well as SSL, WPA and 802.1x user authentication using passwords or certificates. VPN support is also provided. From a personal area network (Bluetooth/infrared) perspective, peer-to-peer connections require interaction in order to accept data and CSPs are available to block both Bluetooth and IrDA object exchange (OBEX). By default, Bluetooth is turned off on Windows Mobile 5.0 devices, giving out-of-the-box protection against bluesnarfing (gaining access to personal information data) and bluejacking (unauthorised sending of messages to a device).

Jason summarised his presentation by pointing out that security is often used as a convenient excuse not to deploy mobile technology when what is really required is to establish a mobile security policy and to educate users.

A risk assessment must be made of each security scenario and risk management should be based on that assessment. Solutions should be automatically enforced but must also be acceptable to users (e.g. complex passwords will not work well on a smartphone!). Security is a combination of both a policy and technology but the policy must come before the technology choice (only when it is known what is to be protected from whom in which situations can it be decided how to secure it).

Suggested further reading
Microsoft mobile security white paper
Windows Mobile network security white paper