Chapter 5

Managing and Controlling Devices

In This Chapter

Understanding mobile device management

Distributing and controlling applications

The smartphone explosion has been fast and furious. Almost overnight, tens of millions of smartphone devices have been sold. Because you’re reading this book, we assume that some of them are in the hands of your users, and they are demanding access to corporate data from these devices.

To compound the problem, many of these devices are probably owned by the end users themselves, rather than by your organization. The personally liable (user-owned) device introduces a whole new set of concerns when you’re trying to manage and control these devices. Typically referred to as the “consumerization of IT,” today’s users demand access from their device of choice. Gone are the days when the IT department could provision a single type of computer and a single mobile device to all users that required them. Sure, some strongholds still exist, but with each passing day, more departments are bending to the pressure and beginning to allow these types of devices to access corporate data.

Whether you’re provisioning and managing corporate-liable (company-issued) mobile devices or allowing end users to purchase their own devices, or both, this chapter helps you get a handle on what solutions are available to ensure that the mobile devices in your enterprise have the appropriate policies that will allow you to feel comfortable with even the most basic aspects of mobile device security, such as controlling whether a device has a password. Typically referred to as mobile device management (MDM), these types of solutions help you provision and maintain policies on your organization’s mobile devices remotely.

This chapter also covers application provisioning. When you allow mobile device applications into the network, you need to provide the necessary tools to ensure that your end users are productive. This might include controlling which applications can or can’t be installed on mobile devices, but it might also include an emerging set of technologies that allow you to create your own enterprise app store for your end users.

Finally, the chapter closes with a discussion on our ongoing case study, AcmeGizmo, and what mobile device management and control attributes were most important in the fictional company’s smartphone deployment.

Managing Your Mobile Devices

Mobile device management (MDM) is a broad and ever-expanding category of product offerings from several vendors that allows an organization to manage the full lifecycle of its smartphone deployment — from initial configuration, including security policy configuration, to support and troubleshooting and reporting. These solutions provide much-needed central management and provisioning applications for your enterprise to ensure that the mobile devices connecting to your network are doing so only when they have been properly configured and secured.

Because the mobile device management space is still relatively new and because it is a quickly growing market, there is a lot of overlap across various types of solutions, all of which claim to be MDM solutions. In some cases, vendors that have traditionally been in the telecom and expense management category have added a large number of MDM functionalities. In other cases, security vendors have felt the need to add MDM capabilities to their products. And of course, there are a number of companies that specialize exclusively in MDM. For this reason, choosing an MDM vendor can be easy or difficult, depending on your role in the organization and your primary goals.

The primary focus of this chapter is on the elements of MDM that have a direct impact on the security of your mobile device deployment. That said, there are a few nonsecurity areas of MDM that have an impact on your organization’s ability to deploy and maintain security on these devices; we also cover those areas. In addition, we cover the two most popular protocols leveraged by MDM vendors: Exchange ActiveSync (EAS) and Open Mobile Alliance Device Management (OMA DM).

Managing devices over the air

One of the most important elements of any mobile device management product is the ability to manage devices over the air (OTA). Given the mobile nature of these devices, no MDM strategy would be successful if it required devices to be physically connected to a machine or network periodically.

OTA management is available for every manageable function that we talk about in this chapter. Not only does this allow you to manage devices without ever physically touching them, but it also allows you to centrally manage groups of devices all at once, greatly reducing the time spent on this task.

Commands are sent to mobile devices one of two ways:

SMS: One popular way to send commands to a mobile device is to use short message service (SMS — text messages). For example, an SMS might be sent to a mobile device as part of an enrollment process, with a URL pointing to the MDM server, allowing the user to add a new device under management.

One of the most compelling attributes of SMS is the fact that it is available nearly everywhere. A common example is when a device is roaming into a different country — the user might choose to turn off data services, rendering push notifications useless, but SMS will likely still be available.

A downside of SMS management is that it is available only on devices that are connected to a mobile network with a 3G or 4G radio. Increasingly popular Wi-Fi–only tablets and other mobile devices cannot be managed via SMS.

Push notification: Push notification services are available on many popular mobile device platforms. Push notification accomplishes the same goal as SMS, but leverages Internet-based communication channels to manage the device.

Push notification mechanisms are attractive because they leverage a reliable communications mechanism so that the sender of the notification knows whether that notification reached the end destination. Additionally, a push notification can handle any amount of data and is not generally subject to per-message charges, as is the case with SMS.

A downside of using an Internet-based management channel is that it requires Internet access in order to work. If a user has disabled her data connection, such as when roaming, important updates and notifications might not be possible on that device until she connects to the data service once again.

Your MDM solution might leverage one or both of these techniques in order to manage mobile devices. Both have some weaknesses, as described here. The most robust MDM solutions will leverage both of these techniques as applicable for specific devices and situations.

Initial provisioning workflow

It is useful to understand how the processes of initial provisioning and ongoing management of a smartphone device work. In this section, we step through the initial provisioning process.

Note that the processes described here are the most common processes. In some cases, they have been simplified to only the portions of the processes themselves that are directly relevant to understanding how the device goes from an unknown device to a fully provisioned and manageable device.

Figure 5-1 shows the typical flow of initial provisioning of a device as described here. After you decide to manage a device with an MDM application, follow these steps:

1. Connect the device to the management console or server so that it can be provisioned.

This means that the URL of the management server needs to be entered on the device. You can use one of these two methods to do that:

• Tell the user the URL or send an e-mail with a clickable URL to the user.

• Send the URL via SMS from the management server to the device.

Some solutions initially require the user to download a client application from the smartphone application marketplace. With these applications, the flow is similar, but rather than entering the URL into her mobile phone browser, the user enters it into the management client application.

2. Have the user click the URL or enter it in the appropriate application and authenticate at that login page, verifying the user’s identity.

Upon completion of authentication, the management console typically completes a registration process. At this point, it might verify which policies and configuration to apply to the device based on who the user is, her role in the organization, and the type of device that she is registering.

The management console then sends the appropriate configuration information to the mobile device. Often, this is in the form of a configuration file that the device knows how to interpret.

3. Have the user accept and install the new configuration file when prompted.

This step does involve end user input, and it is important from a security perspective. You certainly don’t want your users accepting updated configuration files from rogue management servers. Make sure that you train your end users on the dangers of accepting unknown configuration files or connecting to other management servers.

After the user has accepted the new configuration file, the device installs the file and is updated with its new settings and policies (the settings and policies described throughout the remainder of this chapter).

The process described here is the typical over-the-air provisioning process employed by mobile device management solutions. There are other options for deployment of the configuration file to the mobile device, including

E-mail: The configuration file can be e-mailed to the recipient as an attachment, which is then installed on the endpoint device. A word of caution here: If you have enforced a policy that restricts the downloading of attachments from e-mail, this would actually conflict with that policy. Ensure that you are not so restrictive that you prohibit your users from installing the security software that you want to see on their devices!

Web-based delivery: The file is placed on a web server that the user browses to in order to install the configuration.

Direct connection to a PC: This option leverages a configuration utility, such as the iPhone Configuration Utility. In this case, the user physically connects his device to a desktop or laptop via USB, and the config file is installed on the device as the device synchronizes to the software on the PC.

Ongoing management

Initial provisioning and configuration of a device is only the first step. After you have devices under management, you are likely to want to make changes to policies and configuration over time.

After the device has gone through the initial provisioning workflow, as discussed earlier in this chapter, it is subject to ongoing management by the MDM server. As you make updates and changes to the configuration, the device will accept those updates with minimal additional end user interaction.

Figure 5-2 describes the ongoing management process in more detail. In the following list, we take a closer look at each step:

1. Complete the initial provisioning process as described in the preceding section.

After this is completed, a relationship between the device and the MDM server is formed, providing the basis and channel for ongoing updates.

2. Make any policy and configuration changes that you would like on the MDM server.

This allows the MDM server to generate an updated configuration file. The MDM server then sends a push notification to the device, indicating that new configuration information is available.

The device then connects to the MDM server, and the updated policies and configuration are sent to the device, typically via a configuration file. The device then executes the new configuration.

Configuring security policies

Several chapters in this book deal with protection mechanisms for mobile devices, such as anti-malware software for the device, or the ability to remotely wipe the data from the device if it is lost or stolen. Those mechanisms are an extremely important part of any smartphone security deployment, but before you begin to roll those out, there are a number of basic configurations or policies that you should set on the device to ensure that it has an appropriately secure configuration. These configuration policies include setting an appropriate password, encrypting data stored on the device, setting network configuration such as Virtual Private Networks (VPNs) and Wi-Fi, and restricting other features of the device itself.

Implementing password policies

Just about every smartphone on the market includes the ability to set a password that is required to access any of the device’s features (other than the emergency call function, which is required by law to be available regardless of whether the device is locked). Unfortunately, the same devices that allow this functionality almost always have password policies turned off by default.

The lack of a required password is a huge problem. Without one, any person who picks up the device can fully access everything on the device, including the data and applications. This is a huge security exposure, and you must be absolutely certain that everyone who accesses your corporate data with a smartphone has a password set on the device — hopefully one that meets your corporate password policy guidelines.

The onus is on you to ensure that every device connecting to your corporate network is configured to support your policies. There are a number of password policy settings supported by most devices. Most of these policy settings are best practices for any password in corporate or personal environments, regardless of what type of device or application you are trying to secure.

Here’s a rundown of password policy settings:

Password required: This is the first and most obvious setting. It would be great if all smartphone manufacturers required an unlock password on all of their devices — not only for enterprises but for end consumers as well.

Minimum password length: This one is simple. The longer the password, the more difficult it is to crack. Password length settings are a double-edged sword. If you make them too short, they are easy to overcome; if you make them too long, they become difficult for users to remember — and users can end up locked out of their devices.

Industry best practices typically recommend a minimum password length of 6–8 characters.

Password complexity: At its simplest, this means that any password must contain a mix of several different types of characters. For example, an organization’s password policy might dictate that a password must contain a mix of upper- and lowercase letters and at least one number, symbol, or punctuation mark.

The more of these types of special characters you require, the more difficult the password is to crack, but you also run a higher risk that the user will forget the password and get locked out, or write it down where others can find it. Both of these are poor outcomes that you want to avoid.

Every smartphone on the market allows the user to answer the phone without typing in a complicated password. Additionally, emergency phone calls are always allowed from these devices without requiring the user to enter the password. All other outbound calls, as well as access to any other features of the device, require the use of the password.

Password aging: Your password policy for your mobile devices should have a password-aging component. This is the length of time between forced changes of a user’s password. For example, you might specify that users change their password once per quarter or twice per year. This component of a password policy is important because over long periods of time, the likelihood that someone will find out or guess a user’s password increases.

Password history: This setting allows you to control the number of new passwords that must be used before a user can begin to reuse prior passwords. Your password-aging policy won’t be nearly as powerful if the user switches every quarter between the same two passwords. Most good password policies require at least four unique passwords before an end user can reuse a prior password. Device settings typically allow for much higher numbers than that, enabling you to effectively ban reuse altogether if you so choose.

Idle timeout: This setting allow you to specify the amount of time that a device can remain idle, with no user input, before it is locked automatically. The idle timeout setting is an important part of your password policy, because without it you must rely on end users to always lock the devices themselves, which is a very unreliable form of security. With this component of your policy, you want to strike a balance between security and usability. If your devices automatically lock after 30 seconds of inactivity, for example, your users will be constantly re-entering their passwords and losing productivity. If, on the other hand, the devices don’t lock for 24 hours after the last activity, you have a huge window of exposure if that device is lost or stolen. A best practice recommendation is to set devices to lock after 5 minutes or fewer of inactivity.

Maximum number of incorrect passwords: If someone steals a mobile device that has been locked, they are likely to try getting into that device using brute-force password guessing. For this scenario, you want to have a policy enabled that specifies how many times an incorrect password can be used before the data on the device is deleted. Without this type of policy, the thief can continue to guess passwords indefinitely. A best practice for this policy is to set a maximum of 10 incorrect passwords before the device is remotely wiped.

Make sure that your end users know that if they type in the incorrect password too many times, their data will be deleted. This is a good thing to inform users of both in security policies that they review, as well as in any training that you conduct to educate them in the proper use of their mobile devices.

Of course, it’s also a good idea to ensure that you are continually backing up data on the device, just in case it ends up getting wiped. You want to protect your corporate data, not lose it altogether. Chapter 12 covers how to back up and restore data onto existing or replacement devices.

Beyond settings that you can control via configuration on the devices themselves, any good password policy also has an end-user training and education component. The same must hold true for your mobile device password policy. You should train your end users to follow these guidelines:

When creating passwords, never use words found in a dictionary or commonly used words.

For example, an end user should never use his child’s name or the name of his pet as his password.

Never write down your password — anywhere.

This means, of course, that end users shouldn’t write down their passwords on a sticky note on their desk or monitor, but it also means that users shouldn’t write down passwords in locations that they feel are more secure either — such as in their home or on a piece of paper in their purse or wallet.

Never tell anyone your password.

This is true of the user’s boss, the IT administrator, friends, family, and so on.

Never talk about the type of password that you use or the password format.

If a malicious person knows that the password contains a number, is six letters, and is based on your most recent vacation, that person has a strong start on cracking your password. Ensure that your end users don’t make it easy for someone to beat your password policies.

A good combination of strong password-enforcement policies along with end user education and training will ensure that your risk exposure, should a device be lost or stolen, is minimal. This definitely does not mean that a strong password policy is all that you need; this is just one small component of an over-arching security strategy that you will put in place based on this chapter and on the topics covered in the rest of the book.

Removing prohibited applications

Increasingly, MDM solutions allow an organization to restrict the user’s ability to download or use prohibited applications. In some cases, the MDM solution has the ability to uninstall a prohibited application. This is typically in addition to any application removal that an antivirus solution would provide for the device.

Antivirus typically handles applications that are known to have malicious intent. The ability to remove applications via an MDM solution is geared more toward applications that, for one reason or another, the organization does not want to have installed on the device. The reasons can range from security concerns about the application itself (such as the potential for the application to inadvertently leak sensitive information) to productivity concerns (if a user is spending too much time using their social networking application, for example).

Encrypting data

Encryption of data at rest, data that has been downloaded to and will be stored on the smartphone itself, is an important policy to set. Encrypting data prohibits someone from connecting a stolen smartphone to a PC and synchronizing sensitive data from the device to her PC, as an example.

Depending on the operating system platform and device, encryption functionality may or may not be built into the mobile device. In some cases, such as with Apple iPhones running iOS 4, encryption is built into the device. In other cases, encryption is not provided in the base device and operating system, so third-party software is required to accomplish encryption. Increasingly, operating system vendors are including encryption capabilities in the operating system itself, so the primary task is to ensure that encryption is enabled.

For those platforms that include encryption, the task of managing that encryption should be handled by your mobile device management solution. You want to ensure that encryption is enabled across the entire device, especially for any data downloaded to the device, including files, application data, and so on.

Be very careful to ensure that when you enable encryption, you know exactly what is being encrypted and what isn’t. For example, the default encryption policy on a device might encrypt data on the device disk itself — e-mail, contacts, calendar, and personal documents — but might not encrypt data saved to removable media such as an SD card, for example. If that’s the case and you simply implement default encryption settings, you will be leaving yourself open to a critical security vulnerability and an easy way for data to be lost or stolen.

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 Alliance 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 chapter 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.

Some operating system vendors also allow for the creation of enterprise application stores, which are entirely separate from the consumer version of their application stores. For example, in 2010, Apple made it possible for enterprises to create their own application stores for iOS devices through the iOS Enterprise Program (part of Apple’s iOS Developer Program). There are also some third-party and open source tools that allow you to create your own Google Android application stores.

With these enterprise application stores, not only is application distribution limited to only selected applications, but you can also create and distribute your own applications outside of the stringent restrictions sometimes put on applications before they can be posted to consumer application stores. Enterprise application stores also allow you to keep your applications from others, limiting distribution to employees only.

Blacklisting and removing applications

Along with provisioning of applications comes monitoring and control. As with PCs, many organizations have policies that dictate the types of software that can be present on a corporate-owned and -issued device, for example. In this case, the ability to inventory, blacklist, and remove applications becomes important.

The first step in the process is taking an inventory or snapshot of the applications present on a device. Of course, this needs to be done repeatedly throughout the life of the device to ensure that when new applications are added, they fit within the corporate policies and guidelines. Application inventory can also help you determine whether a device has some of the required applications — important information that you can use to determine which applications to provision to a particular device.

Blacklisting applications is a critical step toward ensuring that unwanted applications don’t find their way onto employee devices. An increasing number of MDM solutions allow you to blacklist unwanted applications and prevent users from installing these applications on their mobile devices.

You need to be careful about how restrictive your application download policies are. Because many of the devices making their way onto corporate networks are consumer- or employee-owned devices, it can be difficult or impossible to enforce such policies. Even for company-owned devices, it can be a challenge to restrict usage on these devices to only corporate-approved applications.

Finally, the ability to remove unwanted applications that have found their way onto devices might be something that you require from your MDM solution. This is exactly as it sounds: the ability to remove applications from a device based on the application inventory that the device is reporting to the MDM solution.

Case Study: AcmeGizmo Application Control Deployment

Returning to our ongoing case study on AcmeGizmo, Ivan, the IT manager, is now determining the various policies he will implement for mobile device management. His view is that with the appropriate choices here, he will be able to simultaneously strengthen the security of the AcmeGizmo mobile device deployment and increase user productivity.

Your password, please

Ivan’s first task is to implement a password policy for AcmeGizmo’s mobile device deployment. In the security policy that he created (as discussed in Chapter 4), he specified this: “All devices must have a lock timeout of 10 minutes or less, as well as a lock password with a minimum of 6 characters. All passwords must contain at least 1 non-alphanumeric character.” The enforcement policy that Ivan ended up creating is a bit more complex than that, as shown in Table 5-1.

The password policy that Ivan implemented has the following elements:

Required password: All mobile devices on the AcmeGizmo network are required to have an unlock/power on password.

Required alphanumeric character: Passwords must have at least one letter.

Minimum password length: All passwords must be at least six characters long.

Required nonalphanumeric character: All passwords must contain at least one symbol.

Maximum password age: Every password must be changed at least once per year.

Autolock device: All devices must be set to automatically lock after five minutes of inactivity.

Password history: A user must not reuse any of his or her last five passwords.

Maximum number of failed attempts: After 10 incorrect attempts at a password, the disk on the device will be wiped (deleted) automatically. A device wipe typically does a “factory reset” of the device itself, removing all data except what was on the device when it was purchased.

Ivan has implemented all of these policies through AcmeGizmo’s mobile device management solution, across the entire breadth of devices connecting to AcmeGizmo’s network.

Network settings

Ivan recognizes that being able to connect to the appropriate networks not only improves productivity, but also increases the security of the AcmeGizmo deployment. As a result, he uses the AcmeGizmo mobile device management solution to preprovision the corporate wireless LAN SSID (service set identifier) and WPA2 settings on every device. Through this mechanism, when users enter the corporate offices, their devices will automatically connect to the AcmeGizmo Wi-Fi network, AG_Wireless.

Ivan has not leveraged this solution to provision VPN profiles. In Chapter 7, we describe AcmeGizmo’s SSL VPN deployment using Junos Pulse. With this solution, users have an application deployed on their smartphone devices that connects them to the VPN as needed, so Ivan doesn’t need to remotely set the VPN in the native device settings.

Other settings

Ivan has taken care to minimize the number of restrictions he is placing on each device. He knows that these devices are owned by the end users, not by AcmeGizmo, so he’s concerned about user backlash, should his policies be too restrictive. That said, he does have security concerns to keep in mind, so he has implemented the following additional configurations on each device:

Restricting removable media access: His corporate security policy states that users should not permanently save sensitive corporate data to mobile devices, primarily because there have been several issues in the past, including when Ed from Engineering recently left the company’s next-generation widget designs on a device that ended up being stolen. So Ivan has taken the step of restricting access to removable media because media such as SD cards make it much easier for users to lose or steal corporate data.

Blacklisting applications: Ivan implemented a mobile device management solution that allows AcmeGizmo to remove applications that may be cause for security concerns. He has already blacklisted a number of known phishing applications that he has seen in the news, and he plans to continue monitoring the application inventory across the AcmeGizmo deployment to verify, to the extent possible, potentially malicious applications. As we discuss in Chapter 10, Ivan plans to leverage anti-malware functionality in his Junos Pulse deployment to remove the overhead associated with tracking these potentially malicious applications.

Mail server access: Several users had previously called Ivan to try to figure out how to connect their mobile devices to the corporate e-mail server so that they could download their mail, calendar, and contacts. Despite having created a very clear instructions document, Ivan was still getting these calls. As a result, he decided to preprovision access to the corporate Microsoft Exchange e-mail server on each device.

Application provisioning

As of right now, Ivan leverages his mobile device management solution to provision a handful of applications to mobile devices.

Ivan has started to take a look at a number of vendor products that offer a corporate application store. Moving forward, this is something that is of particular interest to Ivan. He has not yet chosen to implement such a solution, but recognizes that several business units within AcmeGizmo are requesting that he provision more and more applications to corporate devices. His view is that an employee self-service portal will make it easy for employees to figure out exactly which applications they need in order to do their jobs productively.