Anywhere Access and Mobile Security

By Chip Vollers, Sr. Product Manager, Microsoft Mobile Communications

See other Security Tip of the Month columns

Organizations are experiencing an increase in the number of employees using mobile devices to get their work done while on the move. Managing an ever-expanding fleet of mobile devices while ensuring end-to-end data integrity is a difficult task for any organization. IT managers are looking for flexible, end-to-end solutions for single-point access of line-of-business (LOB) applications and company data on mobile devices. These solutions must be designed for efficient control of devices while offering reliable, low-cost, and consistent manageability that works well with an enterprise’s existing infrastructure. The following are a few key areas that IT professionals should consider when deploying mobile solutions.

Authentication: Helping to Ensure Trust Between the Mobile Device and a Company Network

The underlying building block for protecting mobile data integrity is authentication between the mobile device and the servers within the company network that manage data distribution to a variety of nodes, endpoints and clients. Authentication is the key trust-ensuring function that allows or denies a mobile device (and by extension, the user of that device) access to data within a company network. Supporting authentication are certificates and keys through a process called “validation.”

Although certificates are visible and well known, keys represented by the certificate are the more important components for ensuring trust. Cryptographic Service Providers (CSPs) generate and maintain the keys. They come in many different sizes, but there are two basic kinds: symmetric and asymmetric. Because certificates are typically associated with asymmetric keys, otherwise known as a public-private key pair, we’ll focus on public-private key pairs in this section.

A key pair consisting of the private and public key is generated using key generation algorithms in the CSP. The public and private key pair has an arithmetic relationship that mitigates spoofing through a very low probability of guessing one key based on the other. The private key is the secret that is the true identifying piece of information for the entity that it represents. It is imperative that the secret of the private key be maintained (usually through encryption). On the other hand, the public key is built to be distributed to other entities as much as necessary. In Windows Mobile powered devices, the base CSPs store private keys in encrypted form within the protected portion of the registry although custom CSPs can be developed that support physically separated private key stores.

There are many uses for the arithmetic relationship between public and private keys. However, none of these applications can be used unless the key pair is associated to a known entity and the association can be trusted. Certificates associate the public key to the entity they represent. Furthermore, certificates present a way to check their validity so that the association can be trusted. When the key pair is generated, the client goes through a process with a Certification Authority (CA) to create a certificate and associate it with the key pair. This process is called certificate “enrollment.” The enrolled certificate can be published to directories so that other clients and servers can access the certificate and public key for any cryptographic operations that are needed with the client that has the private key.

When one entity, such as a computer or user, asserts its identity to another using its own digital certificate, the recipient must “validate” the certificate to ensure that it is trusted. This is done using root certificates. A root certificate is located in the recipient’s “ROOT” certificate store.

Secure Sockets Layer (SSL): Helping to Protect the Mobile Communication Channel

SSL is a key technology that uses certificates and keys. With SSL, the client always needs to authenticate the server to ensure that it is exchanging data with a trusted partner. Therefore, the Web server sends its own certificate to the Web client (mobile device). The client examines the server certificate and ensures that the certificate “chains” to a root certificate that is in its local root store. After successful authentication of the server certificate, the HTTPS connection is encrypted using session keys.

On Windows Mobile powered devices, there are root certificates included out of the box in the HKLM (local machine) “ROOT” certificate store that can be used for SSL server authentication. However, the correct root certificate may not be preinstalled on the device. In these cases, SSL will fail. In Windows Mobile 6, a user running under the SECROLE_USER_AUTH security role can add Root and intermediate SSL certificates to the device without sacrificing the security of OMA Device Management SSL connections.

Microsoft strongly recommends that enterprises use SSL to encrypt the channel between the mobile device and Microsoft Exchange Server. This deployment step is relevant regardless of the size of your organization. Most Certificate Authorities vendors who sell SSL certificates already have their trusted root certificate on Windows Mobile powered devices, so you may not need to install new SSL certificates.

Another best practice is to pass all Internet traffic for Exchange ActiveSync through a reverse proxy and firewall, such as Microsoft Internet Security and Acceleration Server (ISA) 2006 (see figure below). ISA Server 2006 and Exchange Server 2007 enhance security features by providing data packet inspection in addition to SSL bridging and user authentication.

The ISA server can act as the advanced firewall in the perimeter network that is exposed to Internet traffic. It directly communicates with LDAP servers and internal server computers running Exchange Server. All incoming Internet traffic over port 443 is intercepted by the ISA 2006 Server. The ISA server terminates the SSL connection, authenticates the client to the domain controller via LDAP, and inspects the request. If it is well formed, it sends the request on to the Exchange Client Access server for processing. This adds an additional layer of security to your network.

Windows Mobile Security Model: Allowing Device Control and Access Only When Needed or Authorized

Windows Mobile powered devices employ a combination of security policies, roles, and certificates to address configuration, remote access, and application execution. Security policies provide the flexibility to control access to the device. If a user or application is allowed access, security policies control the boundaries for actions, access, and functionality. The following are some of the ways you can use security policies on Windows Mobile powered devices:

• Control which applications can run on the device and what they can do.

• Control who can access specific device settings and what their level of access is.

• Control what desktop applications can do on the device (e.g., Remote API [RAPI] control through ActiveSync).

Policies configure security settings that are then enforced with the security roles and certificates. Security roles determine access to device resources, based on message origin and how the message is signed. Certificates are used to sign executables, DLLs, and CAB files that run on Windows Mobile powered devices.

Application execution is based on permissions. Windows Mobile devices have a two-tiered permission model (privileged and normal) for determining how applications run. Applications running at the privileged level have the highest permissions; they can call any API, write to protected areas of the registry, and have full access to system files. In reality, few applications need to run as privileged. In fact, allowing them to run privileged allows them to change the operating system environment, which can threaten the integrity of the device. Most applications should run at the normal level. They cannot call trusted APIs, write to protected areas of the registry, write to system files, or install certificates to protected stores.

Applications do not run if blocked because they are not allowed to execute. An application could be blocked because it is not signed by an appropriate certificate, because the user blocks it after being prompted, or if the application is blocked by policy – for example an enterprise policy.

The security policy of a particular device determines how the device handles application signatures and permission. The first part of the security policy is known as access tiers; devices can have one-tier or two-tier access.

• A device with one-tier access focuses only on if an application should run based on whether the application is signed with a certificate in the device certificate store. There is no concern with permission restriction.

• A device with two-tier access restricts application start and run-time permissions. In two-tier devices, applications running privileged have the MANAGER role, and those running normal have the USER_AUTH role. Most applications only require normal permissions to run.

Advanced Device Management: Managing Mobile Devices Like Any Other Client on the Company Network

When evaluating advanced device management and security platforms, IT professionals should consider solution options that allow mobile devices to be managed and policed like any other client on the company network. Platforms such as System Center Mobile Device Manager (MDM) that use Active Directory/group policy allow IT professionals to set and control policies in a single environment. Other key areas for IT professionals to consider related to advanced device management include:

• On-device file encryption: helps prevent theft or loss of company data through expanded on-device security of sensitive company information.

• “Always on” optimized connection (when connected to a carrier’s wireless network or a Wi-Fi connection): helps execute remote device wipe in the event of the theft or loss of the device and enables mobile LOB applications that require persistent connectivity. The mobile VPN in MDM is specifically built to offer a consistent end-user experience, including support for seamless connectivity across different wireless environments with inter-network roaming capabilities and fast reconnect for session persistence.

• Ability to lock down communications and resource capabilities: for compliance and confidentiality purposes, this should include the ability to disable Bluetooth, SMS/MMS, WLAN, Infrared, POP/IMAP e-mail, as well as camera functionality. Look for an “allow” and “deny” functionality for applications that provides enterprises with control over which applications are installed on their employees’ mobile devices.

• Single-point, firewall-protected network access: enhances security with a single-point, behind-the-firewall access to company data and LOB applications on mobile devices. MDM achieves this with Windows Mobile devices through a cutting-edge mobile VPN optimized for the mobile environment.

• “Double envelope security” architecture: provides an added level of protection by authenticating both the device and user, allowing for a single security–enhanced point of access for mobile application traffic and ensures more secure over-the-air certificate handling and installation.

As mobile devices have become increasingly common and powerful, companies have come to rely on them more and more. At the same time, companies face a much broader landscape of security threats than they did in the past. Because mobile devices combine powerful capabilities with small form factors that are easily stolen or lost, protecting the information on these devices has become a priority for many organizations. Efforts to reduce IT management costs have also led to widespread deployment of desktop management solutions. Because mobile devices share many of the same characteristics of desktop systems, there is growing interest in management solutions that can provide the same degree of assurance for asset management, inventory, and protection for mobile devices.