As mobile devices become more common, protecting the data stored on them becomes a primary concern for the enterprise. Fortunately, mobile operating systems now include security features that enterprises can use to enforce corporate policies. In this series, we explore data protection on today's most popular mobile device operating systems: BlackBerry, Windows Mobile and Symbian.
Protecting data on your BlackBerry devices
Protecting data on your Symbian devices
Protecting data on your Windows Mobile devices
|Protecting data on your BlackBerry devices|
In this section, we explore BlackBerry security capabilities most directly related to data protection. You'll discover how tight IT controls and protection options can be combined to safeguard your enterprise's valuable data on a BlackBerry.
For many employers, the data on a handheld is far more valuable than the device itself. According to Ponemon Institute, the average cost of a data breach has now reached $197 per compromised record. The vast majority of breaches involve laptops, but it's just a matter of time before some CEO's lost BlackBerry makes headlines. Or is it?
Under my thumb
Most BlackBerry users carry a device that is centrally configured and monitored by their employer. Although BlackBerrys have long been available to individuals, BlackBerry has until recently been marketed almost exclusively to corporations. In particular, mobile device management through the BlackBerry Enterprise Server (BES) has been a big part of BlackBerry's business appeal.
IT staff use BES to deploy IT and application policies that control how a BlackBerry operates, the programs it can run, and how it will protect data. Global policies are defined for the entire domain and refined to reflect the needs of each group. All authorized BlackBerry users are bound to an IT policy, which can be pushed to their handhelds over-the-air during "wireless enterprise" activation.
Through IT policies, employers can enforce common mobile security needs like mandating device passwords with a minimum length, complexity and update frequency; requiring inactivity timeouts; preventing user changes to read-only parameters; and permitting voice calls on locked handhelds. They can also disable riskier features like Bluetooth or IM and control whether and how data is encrypted.
Application policies go beyond those native capabilities, letting employers control custom and third-party applications installed on the device and the resources they are permitted to access. For example, an application can be permitted to reach internal and/or external domains or prohibited from using Bluetooth or GPS.
Controls like these can reduce risk. For example, BlackBerrys have flown under the radar for mobile malware by running only IT-vetted applications. This may change as consumers configure their own BlackBerrys to run non-business applications.
Digging into data
No matter who manages a BlackBerry, that device's content can be protected through a combination of hardware, software and policies. When the content-protection option is enabled, a random 256-bit AES content-protection key is used to produce a public/private key pair. The content-protection key and private key are then encrypted with a temporary key, derived from the user's password, and stored in flash memory.
As long as the BlackBerry is unlocked, data received by or typed into the device will be encrypted with the content-protection key. Once the device is locked, that content cannot be read until the user enters the correct password, allowing the content-protection key to be decrypted. Furthermore, any messages received while the device is locked are encrypted with the previously generated public key and cannot be decrypted with the private key until the user's password has been entered.
This scheme prevents someone from picking up a locked BlackBerry and viewing user data (including text typed into the BlackBerry), any data saved by the BlackBerry Web browser (including its cache), calendar entries, address book contacts, memos, tasks, and email messages (including bodies and attachments). Further options can encrypt files written to external memory and passwords saved by a Password Keeper application.
IT policies control whether or not content protection is used and the length (strength) of associated keys. Policies also control whether users can make exceptions, like viewing the address book on a locked BlackBerry. It is important to realize, however, that content protection depends on the user's password. This entire scheme can be defeated by an easy-to-guess password.
To deter password compromise, define IT policies that discourage practices like reuse and simple password incrementing. Combine those with secure data wipe after max. password attempts or device loss/theft. BlackBerry policies also let you automatically wipe a device if it isn't unlocked within a defined period or if the battery becomes too weak to receive a remote wipe command.
Going the distance
These measures protect data at rest on a BlackBerry, but what about data in transit? The BlackBerry operating system is well known for including transport encryption, but it actually supports multiple methods -- some of which affect stored data too.
Every message sent to a BlackBerry through a wireless carrier is routed through RIM's BlackBerry infrastructure. For customer privacy, each message is encrypted with 3DES or AES and keys known only to the BES and the handheld. The BES decrypts each message before relaying it to your company's messaging server (e.g., Microsoft Exchange, IBM Lotus Domino).
Some newer BlackBerrys support further over-the-air encryption options, including IPsec tunneling to a corporate VPN gateway and Wi-Fi data encryption using WPA/WPA2. All of these methods deter eavesdropping on messages in transit. But some companies require end-to-end encryption, from sender to recipient. How can a recipient know that a message was not modified or viewed on the messaging server?
BlackBerry handhelds support end-to-end encryption through optional PGP or S/MIME clients. For example, when the BES delivers an S/MIME-protected message to a BlackBerry, both BlackBerry transport encryption and S/MIME data encryption are applied. Upon receipt, the handheld removes BlackBerry transport encryption, but S/MIME data encryption remains until the recipient views the message.
In this section, we explored BlackBerry security capabilities most directly related to data protection. We have shown how tight IT controls and protection options can be combined to keep BlackBerry data safe. To learn more about the BlackBerry security architecture, including capabilities that go well beyond data protection, visit www.blackberry.com/security. Remember: Your mobile device vendor can only supply the tools to secure your mobile workforce -- it's up to you to apply them wisely.
|Protecting data on your Symbian devices|
According to In-Stat, Symbian leads the smartphone operating system field with almost 70% of the global market, while the biggest Symbian player -- Nokia -- continues to out-ship every other wireless handset vendor. It therefore comes as no surprise that Symbian was targeted by the first significant mobile malware outbreak.
When SymbianOS.Cabir emerged back in June 2004, mobile vendors were put on notice that handhelds had matured sufficiently to lure attackers. Cabir was a simple worm that posed as the Caribe Security Manager utility, but it implanted malicious code that spread to other Nokia Series 60 devices over Bluetooth. Shortly thereafter, sibling Mabir exploited multi-media messaging service (MMS) in a similar fashion. Although these worms did no real damage, they showed how unprotected those handheld devices and their data were.
In Cabir's aftermath, all major mobile operating systems were overhauled to incorporate protection features that prevented malware from overwriting sensitive files, including privileged OS components and device data.
First came Symbian-Signed, a program whereby registered software publishers could digitally sign applications that had been tested by a Symbian-accredited test house. This program has undergone revision to make signing less onerous for smaller developers. Today, there are three Symbian-Signed levels: Open-Signed (limited/internal use), Express-Signed (self-tested), and Certified-Signed (independently tested).
All three levels use digital signatures to bind software to publisher identities. Express-Signed and Certified-Signed programs must use Publisher IDs issued by TC TrustCenter, the official Certificate Authority for the Symbian-Signed program. The objective is to enable third-party software development while giving users a reliable way to identify software origin and trustworthy publishers.
Hardening the platform
Symbian 9 built upon this foundation by implementing Platform Security -- an architecture designed to restrict or block unauthorized access to APIs and data. Platform Security replaces the old "all or nothing" execution environment, where every installed program had unfettered access to everything else on a Symbian handheld. Instead, Capability Management now controls the access rights afforded to each running process, while Data Caging confines each process to its own part of the file system.
On Symbian 9.x devices, signed executables are tagged with capabilities that can be permitted or denied at run-time, based on configured policies. Full API and file system privileges are reserved for the Trusted Computing Base (i.e., the kernel, file system, and software installer). System privileges grant Trusted Computing System servers like messaging selective access to device data, network interfaces, and power management. Finally, there are basic privileges, like the ability to read and write user data, use network services, and determine device location, which can be configured by users.
Capability Management is not impervious to hacks, but it helps Symbian devices resist unauthorized software installation, maintain system integrity, and lock down sensitive operations and data. To further protect data, capabilities are combined with Data Caging -- a straightforward way of keeping code, read-only public data, and per-application private data strictly separated. For example, files in the /resource directory are visible to all processes but can be deleted or changed only by the Trusted Computing Base. However, the files within each /private/SID directory are hidden from executables other than the one associated with a given SID (Secure Identifier).
Symbian Platform Security is concerned with controlling API and data access but not with maintaining data confidentiality. The Symbian operating system does indeed implement several encryption algorithms, including DES, 3DES, RC2, RC4, RC5 and AES. The operating system does not, however, automatically encrypt folders, files or messages. Deciding whether and how data should be encrypted falls to each application.
For example, enterprises that require cryptographic protection for email messages may choose to send them over TLS, IPsec or another encrypted channel. If TLS is chosen, a Symbian device can use built-in functions to encrypt the IMAP or POP3 messages exchanged with each configured mail server. But those mail messages and file attachments stored on a Symbian device will not remain encrypted "at rest" unless a third-party stored data encryption solution is installed and configured to do so.
Many such programs are commercially available for Symbian handhelds, from basic standalone programs that individuals can use to encrypt passwords and credit card numbers, to centrally managed enterprise file/folder encryption solutions. To learn more about third-party programs for Symbian devices (including data encryption programs), consult your carrier or device manufacturer, or search at Symbian software website like www.my-symbian.com or www.phonesymbian.com.
|Protecting data on your Windows Mobile devices|
Until recently, Windows Mobile devices lacked the native management and security capabilities long associated with BlackBerrys. Many third-party device management and security solutions were (and still are) available for Windows Mobile. However, Windows Mobile simply did not have BlackBerry's "protected-out-of-the-box" appeal. With System Center Mobile Device Manager, Microsoft has moved to fill this gap.
Work in progress
Today's Windows Mobile 6 devices are descended from many generations of Windows CE PDAs and Pocket PCs. Those older mobile operating systems were certainly not devoid of native security capabilities. They were simply incomplete and hard to manage.
For example, Windows Mobile 2003 Pocket PCs included PPTP and IPsec VPN clients, but they were not enabled by default. Moreover, those clients could not be IT-configured over the air without jumping through extra hoops (e.g., syncing XML provisioning documents or using a third-party mobile device manager). Any data received by those devices was stored in decrypted form -- unless a third-party crypto product was added.
In short, enterprises that needed to centrally manage and secure Windows Mobile devices had to assemble the piece parts and fill in critical gaps.
A new generation
Starting with Windows Mobile 6.1, Microsoft-based smartphones and PDAs have an alternative: Microsoft's System Center Mobile Device Manager (SCMDM) 2008. All WM 6.1 devices are inherently capable of being managed by an enterprise SCMDM server. Depending upon your needs and configuration, that server can provide fully automated over-the-air device provisioning, software installation, policy enforcement, and monitoring/reporting.
To enroll with SCMDM, a WM 6.1 user just enters his enterprise email address and an administrator-supplied one-time PIN. The WM 6.1 device uses SSL to connect to an SCMDM gateway server (i.e., a 64-bit Windows 2003 Server reachable from the Internet, outside the enterprise's trusted intranet).
That gateway authenticates the user and completes enrollment by interacting with a device management server (i.e., another 64-bit Windows 2003 Server, located inside the intranet, with access to Active Directory). These SCMDM server functions can be further distributed -- for example, delegating persistent storage to a separate SQL Server, or using a separate Microsoft CA to issue device certificates.
Once a WM 6.1 device has been enrolled and "boots-strapped," all further communication between the PDA/smartphone and gateway is protected by an auto-configured IPsec "mobile VPN" tunnel. SCMDM can provision Windows Mobile devices by using the Windows Software Update Service (WSUS) 3.0 to push application packages over the air. SCMDM also installs and enforces IT-defined Active Directory Group Policies -- to deny use of selected network interfaces and applications, for example, or encrypt specified files or folders.
Thereafter, each managed Windows Mobile can be centrally monitored and updated through the SCMDM. New software can be pushed through WSUS. Device hardware and software can be periodically inventoried. If a managed Windows Mobile is ever lost or stolen, the SCMDM can be used to remotely wipe the device the next time it connects to the enterprise network.
Note that SCMDM does not rely on Active Sync. Instead, WM 6.1 devices automatically reconnect their mobile VPN tunnel to the SCMDM gateway whenever a 3G or Wi-Fi link becomes active. Bear in mind, however, that most nomadic mobile devices still spend some time out of range and thus disconnected from every network, including the SCMDM.
Finally, that mobile VPN tunnel can also provide a secure conduit for enterprise application access -- for example, letting Windows Mobile users connect to Exchange, Sharepoint, and other application servers inside the enterprise firewall. Even applications that apply their own data protection measures, like TLS-encrypted POP and SMTP sessions, can be relayed through the mobile VPN tunnel.
Where SCMDM fits
With SCMDM, Microsoft provides a "protected-out-of-the-box" solution for enterprises that use new Windows Mobile devices. However, SCMDM cannot manage older Windows Mobile devices, including today's dominant Windows Mobile 6.0 population. Given the short lifespan of smartphones, many older devices may never be soft-upgradeable to 6.1 -- instead, you'll have to buy new hardware to tap into SCMDM.
Moreover, like BlackBerry Enterprise Server, SCMDM is not (currently) a cross-platform solution. Organizations with diverse mobile device populations will either need to deploy multiple MDM "silos" or invest in a third-party MDM like Sybase iAnywhere, Nokia Intellisync, or Motorola Good, with agents for multiple operating systems.
While SCMDM provides a relatively broad set of management and security capabilities, no platform can be everything to everyone. For example, those who require over-the-air remote control still need a third-party solution. Finally, SCMDM is Microsoft's first foray into mobile device management; it will no doubt require refinement and hardening over time. Visit Microsoft to learn more about Windows Mobile 6.1 security and Microsoft's SCMDM approach to Windows Mobile data protection.
About the author: Lisa Phifer is president and co-owner of Core Competence, a consulting firm focused on business use of emerging network and security technologies. At Core Competence, Lisa draws upon her 27 years of network design, implementation and testing experience to provide a range of services, from vulnerability assessment and product evaluation to user education and white paper development. She has advised companies large and small regarding the use of network technologies and security best practices to manage risk and meet business needs. Lisa teaches and writes extensively about a wide range of technologies, from wireless/mobile security and intrusion prevention to virtual private networking and network access control. She is also a site expert to SearchMobileComputing.com and SearchNetworking.com.