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:
Figure 5-1: Provisioning workflow.
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:
Figure 5-2: Managing devices.
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.
Mobile Device Security For Dummies Page 13