Mobile Device Security For Dummies

by Rich Campagna

  Configuring network settings: VPN, APN, and Wi-Fi

  Another critical security-related feature with most MDM solutions gives you control over network connections and the way that each mobile device connects to the corporate environment. Here are several ways that mobile devices connect to networks:

  Virtual private network (VPN) access: Most MDM functions allow you to configure VPN access requirements on a mobile device. It is critical that all connections to your enterprise environment do so through a VPN, and setting the policies on behalf of the user makes it that much easier for the user to be in compliance with your policies. Typically, the MDM solution allows you to specify a VPN gateway, along with the type of user authentication required and any other information required to securely connect to the corporate network. Chapter 7 discusses VPNs in detail.

  Private access point name (private APN): Private APNs are much like VPNs from a security perspective. The APN configuration specifies the point where a mobile device can access an IP network. Many service providers globally provide a private APN service to large customers, enabling them to separate their data traffic from that of other customers, or from customers on their public APNs. MDM solutions can sometimes configure mobile devices to support private APNs.

  Private APNs are a proxy for an IPsec or SSL VPN only if the device is connected directly to the carrier network. For devices that do not have 3G or 4G service, or when devices are connected to Wi-Fi but not to the carrier network, the level of data security and segmentation that a private APN provides is no longer available. Make sure that you are aware of this and plan for it in your security and Wi-Fi access policies.

  Wi-Fi access: Many mobile devices on the market today have multiple radios — one for accessing the 3G or 4G network and another for Wi-Fi access. MDM solutions allow you to configure mobile devices to seamlessly connect to Wi-Fi access points of your choosing.

  For example, you may have an enterprise wireless local area network (WLAN) deployment that you want devices to access when the user is on the corporate campus. MDM allows you to specify the service set identifier (SSID) of the WLAN, and also specify the security settings, such as encryption type and password, required to have the device seamlessly join the network when it’s within range. It is always a best practice to enable encryption on your wireless LAN.

  Many MDM solutions also allow you to select whether Wi-Fi access is allowed from a mobile device at all. This truly prevents users from connecting to insecure or untrusted wireless networks; however, it also has the likely impact of limiting the users’ productivity or forcing them to use more expensive 3G data services, even if free or low-cost Wi-Fi is available in their current location. As with other security mechanisms, disabling Wi-Fi is not without tradeoffs in end-user experience.

  Restricting device functionality

  There is a wide range of device functionality that you may want to restrict or control on your organization’s mobile devices in the interest of security. Not all of the following features are available in all MDM platforms or on all smartphone operating systems:

  Application store access: On today’s smartphones, application stores are extremely popular, with some form of an app store on every major smartphone platform. These stores or marketplaces have revolutionized the way that applications are delivered to a device, and they make it as simple as a single click to download and install an application. These applications are typically free or very low cost, drastically reducing barriers to new software acquisition for end users.

  The primary issue with app stores, however, is that they make it much easier for end users to inadvertently download and install malicious software such as a virus or spyware, as described in the later section “Pros and cons of consumer app stores.” The amount of security scrutiny that posted applications get varies greatly depending on the application store in question.

  It probably does not make sense to restrict access to application stores because applications are a big reason why smartphones have become so popular. Your end users will likely revolt if you try to restrict access. A more feasible option may be to allow access, but to protect users’ devices with many of the other security best practices described in this book.

  Third-party application downloads: This restriction applies to applications added to the device outside of application stores. Because most smartphone operating systems include the ability to install software outside of the application store, this restriction provides additional protection against unwanted applications installed through other mechanisms, such as desktop synchronization. This policy is important because outside of the sanctioned application stores, your users don’t really know who has created the software that they have downloaded. Malicious entities look for these types of application stores precisely because they know nobody is forcing them to validate their identity or reviewing the application before it is posted.

  Removable media access: This setting controls whether an end user can copy data and files to removable media such as an SD card. Many organizations underestimate the threats of data leakage via removable media, but it is a very real threat. It is all too easy for users to copy data onto such media and then lose the media itself because it is typically the size of a postage stamp. It is a good idea to restrict what your users can move from their mobile device to removable media.

  Screen capture: This type of policy controls the user’s ability to take screenshots of what is on the device screen and make that data available to applications on the device. Allowing screen captures is a security vulnerability because a user can essentially remove data from the device without physically e-mailing or sending an attachment, for example. Ensure that if you have very sensitive data on the device, you protect against all mechanisms of data leakage, including screenshots.

  Clipboard operations: Similar to screen capture, these functions allow you to control whether an end user can cut, copy, and paste text on an end device. As with application stores, these features are an important part of your users’ overall smartphone experience, so you likely won’t be successful in restricting these capabilities even if you want to, except in the most sensitive environments. Properly training your end users not to inadvertently leak data is the more likely approach that you will be able to take.

  Bluetooth access: In the past, Bluetooth was viewed as a potential mechanism for breaking into a device or distributing viruses. All smartphones today, however, include a security functionality that requires the use of authentication before pairing devices, greatly reducing the risk of a malicious person bluejacking a device within close proximity.

  Use of the device’s camera: In certain situations, such as in defense-related organizations, users are not allowed to use the cameras on their mobile devices. Typically, an MDM solution gives the organization the capability to enable or disable use of the camera on mobile devices under management.

  Access to consumer e-mail accounts such as Gmail or Yahoo! Mail: Your users might make it difficult to enable this type of policy on devices that they also use for personal reasons, but for a corporate-owned and -issued device, restricting access to consumer e-mail accounts might make perfect sense. Microsoft introduced this policy in EAS (Exchange ActiveSync) 12.1, and it allows the administrator to control whether end users can access consumer e-mail accounts in addition to their corporate-provisioned Exchange e-mail accounts.

  In this section, we have described a range of possible device restrictions that you have at your disposal — a very powerful proposition. Be careful, though, because that power can easily be abused. These restrictions have the potential to severely cut down on the functionality and usability of a mobile device. From a security perspective, that sounds great. From a productivity perspective, however, it’s not very good. At the end of the day, your job is to enable users to be productive without putting sensitive corporate assets at risk; you need to balance restrictions with the needs of your users to get their jobs done.

  Open Mobile Al
liance Device Management

  In many networking and security areas, open standards play a critical role in ensuring operability across different devices. Mobile devices are no different. The Open Mobile Alliance (OMA) was formed in 2002 as a consortium of vendors with a common goal of interoperability for new and emerging mobile technologies. Within OMA, the Device Management Working Group is responsible for management of both software and configuration on mobile devices.

  According to the Device Management Working Group Charter, the working group is responsible for creating standards related to these items:

  Initial configuration of mobile devices

  Ongoing installation and updates of configuration

  Remote retrieval of management information from devices

  Processing of events and alarms generated by mobile devices

  Devices that implement support for OMA Device Management (DM) may implement a subset of the various functions covered by the standards, so not all devices will support every feature. The OMA DM standards were designed with mobile devices in mind, ensuring that battery life, network throughput, and security are covered and adapted to the special needs and requirements of the typical mobile device.

  As your organization proceeds with purchase decisions related to mobile device management, support for standards might be something to take into account. The most compelling reason to look at an MDM solution that supports OMA DM is that as new devices come onto the market, they are likely to support open standards like OMA DM, ensuring that you have investment protection from your MDM solution and the ability to rapidly adapt to new devices as your users attempt to bring them into your corporate network.

  Exchange ActiveSync

  Exchange ActiveSync (EAS) is a proprietary protocol developed by Microsoft that has been widely licensed and adopted by device operating system vendors, and has become a de facto standard over the past few years. Most smartphone operating systems sold today support ActiveSync. Microsoft developed EAS as a synchronization protocol for Microsoft Exchange, but it has been adapted over time to include more device security and management functionality.

  The latest versions of EAS support a number of security policies and settings, some of which include

  Various options for setting password policies, including password length and complexity requirements.

  The ability to remotely lock or wipe a device.

  Tools to wipe and/or encrypt removable media, such as SD cards.

  Controls for whether a device that does not support all of the EAS password policies can connect to the Exchange Server.

  Password expiration and policy refresh intervals.

  Policies that control whether attachments can be downloaded to the endpoint device.

  The ability to disable Wi-Fi, infrared ports, Bluetooth, and cameras.

  Many enterprises implement these EAS security policies when they first allow mobile devices to access their network. Typically, the mobile devices connect directly to the e-mail server via the Internet.

  Always ensure that you are using HTTPS for devices connecting to the mail server via the Internet. You must never allow direct HTTP access because HTTP is unencrypted, and you should never have sensitive corporate data transiting the Internet unencrypted. Unencrypted data, if intercepted by malicious entities, can be captured and read by the receiver of that data. By encrypting e-mail via HTTPS, that data cannot be read, even if it gets into the wrong hands.

  A question that might be on your mind is whether it is still necessary to deploy additional security mechanisms if the aforementioned EAS security policies have been put into place. The answer is a resounding yes. The EAS policies are only a small part of security best practices for deploying mobile devices. EAS covers some of the basics — password policies and the ability to remotely wipe or lock lost or stolen devices — but it doesn’t cover the majority of the security best practices covered throughout this chapter and throughout this book.

  For example, EAS allows all traffic to and from the Exchange Server to be encrypted, but it does nothing to protect traffic to and from other application servers that the user might want to access. Additionally, EAS provides no mechanism for controlling access to application stores or downloading of third-party applications, limiting your ability to control the applications that are downloaded onto your organization’s devices.

  Exchange ActiveSync provides some attractive security benefits, but it is far from a complete security solution. It might be part of a layered approach to smartphone and mobile device security, but it isn’t built to stand alone and secure devices on all levels.

  Controlling Applications

  After a device is provisioned with the appropriate security policies and configurations, you need to deploy the appropriate applications to the device. In some cases, you are doing so in order to ensure that the device is fully secured. For example, you might deploy an anti-malware application to the device. In other cases, it is more about ease of deployment — there might be several enterprise applications that the users in your organization require, and you want to ensure that each of those applications is available.

  The most popular way that consumers acquire applications for their smartphones is through application stores provided by their device manufacturer or by their service provider. This is a potentially useful distribution mechanism for the enterprise as well, but only for certain types of applications — and this approach is not without risks.

  Pros and cons of consumer app stores

  There are pros and cons of using consumer application stores in enterprise environments. On the plus side, this is one of the most ubiquitous distribution mechanisms available. Just about every smartphone on the market today has an immediately available application store, and users have become very comfortable with using of application stores as a way to download and install applications onto their smartphone device. There are, however, very clear dangers and drawbacks to taking such an approach.

  One of the dangers is the fact that many consumer application stores are not closely monitored from a security perspective. Some application stores, such as Apple’s App Store, have fairly stringent screening processes that are required before an application can be posted. Others, such as the Android Market, have less stringent screening processes, greatly increasing the likelihood that an application that makes its way into the application store is malicious. In either case, the risk is there.

  Increasingly, bad actors are sneaking malicious applications into these app stores, and if you leave it to your end users to find software on their own, they might end up with software that simply looks like the software they were seeking. An application that appears to be a commercial customer relationship management (CRM) application might actually be spyware.

  In 2010, several online banking apps were posted to the Android Market. Consumers were led to believe that these applications were published by several very large banking organizations. It turned out that these were not legitimate banking applications; they were posted by a third party that made them appear to be official online banking applications. In this case, the applications were designed for phishing — a clever way to steal end users’ online banking login credentials. With hundreds of thousands of applications in these app stores, it is easy for a user to mistake a fake and malicious application for a legitimate one. You certainly don’t want your corporate data to fall into the wrong hands this way.

  Provisioning applications to mobile devices

  It is not a good security practice to leverage consumer application stores to deliver applications to your users’ mobile devices, so you need to opt for one of the following delivery options, the most popular of which is over-the-air provisioning.

  Over-the-air application provisioning

  Over-the-air application provisioning is exactly as it sounds: Many MDM platforms offer the ability to deliver applications to smartphones over the air, leveraging many of the same mechanisms described throughout this chapte
r for provisioning policies and configurations. With this method, you select the applications to provision and the devices to which those applications should be provisioned and deliver them wirelessly to those devices.

  Web-based provisioning

  MDM solutions provide an easy and packaged method for provisioning applications, but there are easier, less expensive options. One method is simple web-based provisioning, where your organization hosts the appropriate applications on a web server. The employee then clicks the appropriate URL to retrieve the installation package from the web server. The URL can also be provided to employees via SMS or e-mail to make it easier for employees to know where to get the application.

  Applications catalog

  Some solutions on the market offer you the ability to create a catalog of corporate-approved or -created applications from which an employee can choose. These applications can be delivered to the device in one of several ways, including direct download from an application store, over the air delivery, or direct installation of the application to the device through an SD Card or USB connection to a PC.

  In some cases, this online application catalog is nothing more than a pointer to the URL for applications that are hosted on the application store of the relevant app store vendor. For example, you might provide a link to an off-the-shelf customer relationship management application. The advantage of taking this approach versus having the employee look for the appropriate application is that it cuts down on guesswork and virtually ensures that the employee selects the appropriate application, and not a malicious app masquerading as a legitimate application. This approach also makes it easier for employees to get everything that they need to be productive on a smartphone device; they can find all of their recommended applications in one location.