Figure 4-16: Number of apps in app stores.
Typically, application policies can be categorized in the following subdomains, as shown in Figure 4-17:
White listing of approved applications that can be used by end users: As with the other policies we discuss in this chapter, this policy can be interpreted as draconian. Clearly for enterprise-issued mobile devices, this policy can be justified to a degree because the mobile devices are enterprise assets and, therefore, the applications that reside on them can be controlled. However, even in this situation, there is a bonding that develops between the users and their mobile devices, and the users become de facto owners of these devices and assume moral authority over their usage.
Quite obviously, for mobile devices that users own and bring into the enterprise, the actual application policies cannot be readily enforced on the devices. In this situation, you need to rely on the monitoring policies to ensure that enterprise compliance is being maintained when the device is connected to the enterprise network.
Profile settings for approved applications: This policy applies to enterprise-issued mobile devices only, because it controls how applications can be configured and used. We discuss at length in the “Profile setting policies” section, earlier in this chapter, how to supply users with guidelines and recommended profile settings for applications. This is critical not only to ensure that the employee has connectivity and can actually use critical enterprise applications on the mobile device but also to limit the exposure that these applications have from a security standpoint.
Figure 4-17: Application policies categorization.
For employee-owned devices, it’s the user’s prerogative what types of applications that she chooses to install, so there is no control you can exercise over that. However, you can impose restrictions on applications that connect to the corporate network like e-mail.
For instance, a very common profile setting for e-mail applications is to restrict download of attachments. This setting limits the exposure that the loss or theft of the mobile device can have because there aren’t any residual documents on the device that an unscrupulous user can exploit. A less-restrictive version of this policy is to allow download of attachments to onboard flash only and not to removable media.
The BlackBerry Enterprise Server provides an arsenal of enterprise application settings that you can tweak to provide a custom environment that you are satisfied with. It provides a default application control policy that blocks third-party applications from running on a BlackBerry. Or, for the more liberal minded, it allows for application policies white lists to allow a controlled set of third-party applications to run on the mobile device. It can also get very precise and dictate data sets that the application is or isn’t allowed to use, such as contacts, locations, photos, and so on.
User notification of application policy violations: This policy applies to all mobile devices, enterprise-issued as well as employee-owned devices. The detection of these policy violations varies for these two categories. For the former, you may have additional tools at your disposal, including monitoring capabilities on the device in addition to network-based detection. For the latter, you need to rely on your monitoring capabilities on the network to detect out-of-policy application usage.
The response to application policy violations should be enforced in two steps. The first one is a warning notification indicating that the user is in violation of enterprise application policies. This notification could be in the form of a web page in the case of http-based applications, or e-mail in the case of other applications. After a certain number of warnings — spell this out clearly in your enterprise usage policy — the enforcement (the second step) needs to be more brutal. As with other policies, the remediation at this point is to inform the user that his right to connect to the enterprise network may be curtailed. Show users who is the master and commander!
Keep in mind that you can no longer rely on the application store vendors to be gatekeepers to the types of applications that appear on their store. In fact, the Android Market has been plagued with malicious applications. Apple keeps a much tighter leash on the applications that are allowed to be showcased on the App Store, but in spite of these stricter controls, Apple has had its share of unscrupulous apps show up as well.
At the highly regarded Black Hat DC 2010 conference (a premier security event to discuss security breaches and vulnerabilities in hardware and software), software engineer Nicolas Seriot disclosed that two iPhone applications had been pulled out from the App Store because of privacy violations:
Aurora Feint (in July 2008) harvested all the contacts from a user’s iPhone and uploaded the entire contents unencrypted to the game developer’s server.
MogoRoad (in September 2009) uploaded users’ phone numbers to the developer’s server, and the users were then harassed by live telemarketing agents who were peddling products. These are just two applications but are representative of what apps on the loose can do.
Storm8, another popular game developer for the iPhone, was charged in a complaint field at the U.S. district court in Northern California in 2009, about its games surreptitiously collecting user information, mobile numbers in particular.
As we discuss in Chapter 2, jailbroken iPhones should be a source of concern for you. When an iPhone is jailbroken, there is no gatekeeper to ensure that the applications running on it aren’t well-packaged malware. Until December 2010, Apple had a jailbreak-detection API that applications could use to detect whether an iPhone was jailbroken, but for some reason, Apple decided to pull support for this API. You still have a number of third-party applications that you can use to perform similar detection functions should you choose to limit the enterprise exposure to jailbroken iPhones by detecting them and branding them as unsupported devices, primarily because of the opacity surrounding the applications that are actually running on those devices.
To make matters more interesting, some good citizens are actually using the jailbreaking of iPhones to make attacks more difficult. Case in point is a tool called Antid0te, created by Stefan Esser of SektionEins, which adds Address Space Layout Randomization (ASLR) onto jailbroken iOS devices. What this tool does is randomize key memory locations to make it more difficult for certain attacks to locate their target data.
More such applications are likely to emerge, but be wary of embracing apps that don’t have much pedigree in the form of a big reputable firm behind them. You should avoid recommending any applications as part of your defense arsenal that are made by unknown parties. Although some of them may sound promising and make bold claims, these could be cloaked malware or poorly written applications that do more damage than remedy.
Regardless of these advancements, your defensive posture should be taking out support for devices that are not trusted (also known as those that are no longer supported by the manufacturers because of active intervention by the users that change the posture of these devices).
Your users live in dangerous waters regardless of whether they are aware of it, and it falls upon you to protect them from the predators in the guise of applications that threaten to launch an attack anywhere and anytime.
Case Study: AcmeGizmo Mobile Device Security Policy
In this section, we revisit our ongoing case study of AcmeGizmo, which we introduce in Chapter 1. Ivan, our IT administrator, has been doing a lot of research into possible solutions for his mobile device problem, and has also learned quite a bit about the possible issues and threats that he needs to concern himself with when providing enterprise access to mobile devices. He has come up with a fairly comprehensive security policy that covers not only the types of technologies he is going to deploy but also acceptable-use guidelines for employees of AcmeGizmo to follow when using their mobile devices to access corporate data.
Ivan decided to implement a security policy that will allow for maximum productivity but is restrictive enough to meet AcmeGizmo’s overall corporate security needs. The majority of the po
licies in the example security policy for AcmeGizmo are covered in the case study sections in other chapters, but a couple are covered here.
Ivan decided that all employee devices must be registered and approved both by the corporate help desk and the employee’s manager prior to accessing the network. This will not only help Ivan track the devices connecting to the corporate network, but also ensure that the employee’s manager feels that mobile device access will benefit the individual’s productivity.
Ivan decided to include a password policy. Many mobile devices available on the market do not force the user to have a password, but because these devices will be able to access sensitive corporate data, Ivan wants to ensure that a lost or stolen device is adequately protected from someone picking it up and easily having access to AcmeGizmo data. For this reason, Ivan wants to ensure that all devices have a lock time-out of 10 minutes, meaning that if the user doesn’t use the device, it will automatically lock within 10 minutes of inactivity.
In addition, all lock passwords must be at least six characters, with a mix of characters, numbers, and symbols. This is in addition to the one-time password solution being used to connect AcmeGizmo devices to the network via SSL VPN.
Many mobile devices now ship with built-in full disk encryption, but many more do not. Ivan has decided that all devices that ship with full disk encryption must have it enabled (if it’s possible to disable it). In addition, he has chosen third-party encryption software that will be installed on all devices that do not have built-in encryption.
Finally, Ivan established a couple of requirements that ensure that employees follow reasonable acceptable use policies and procedures. These requirements ask employees to use care with their mobile devices to ensure that they do not carelessly leave them unattended, as an example. Additionally, he requests that employees do not download and save sensitive data to mobile devices, as an extra precaution, just in case the device does get stolen. Finally, he outlines a process of contacting the AcmeGizmo help desk immediately if an employee misplaces a device or if the device is stolen.
Here’s the security policy that Ivan wrote for distribution to all employees. As with all good security policies, special care has been taken to ensure that the policy is written in language that end users can understand. Ivan also attempted to keep it as brief as possible, which helps to minimize the confusion that too many rules and regulations can cause.
Overview: This is the AcmeGizmo policy on mobile device usage. A mobile device is any PDA, smartphone, or other portable device that has the ability to access the corporate network and can store sensitive corporate data. (Note that laptops are not included in the definition of a mobile device.)
Purpose: This policy has been designed to ensure that AcmeGizmo employees protect mobile devices and corporate data from theft and loss.
Policy:
All devices used by AcmeGizmo employees to access any corporate data must be approved by IT security and the employee’s manager prior to use.
All devices must run one of the following operating systems:
• Apple iOS 4.0 or newer
• Google Android 2.1 or newer
• RIM BlackBerry (any version)
• Windows Mobile 6.5 or Windows Phone 7
• Nokia Symbian
No other mobile devices are permitted to access the AcmeGizmo corporate network.
All devices must have a lock time-out of 10 minutes or less, as well as a lock password with a minimum of six characters. All passwords must contain at least one nonalphanumeric character.
All devices must have the Junos Pulse client installed and running at all times. This software includes a virtual private network (VPN) component that securely connects the device to AcmeGizmo. It also includes antivirus and personal firewall software. In addition, it gives AcmeGizmo IT the ability to remotely lock, wipe, and locate any mobile device if it is lost or stolen. End users connecting devices to the corporate network agree to installation of such software on their mobile devices.
All devices must have encryption enabled, or a third-party full disk encryption product installed.
Employees must employ all reasonable means to ensure that mobile devices are not lost or stolen, which requires extra diligence on the part of every employee to mitigate carelessness.
Sensitive corporate data must not be downloaded to mobile devices. Data access is restricted to corporate e-mail, the corporate CRM application, and the company intranet. Sensitive attachments received via e-mail must not be stored permanently on the device disk drive or on any removable media.
Employees must immediately report any lost or stolen devices to the help desk. Lost or stolen devices may be subject to a full wipe (erasure of the disk) when reported lost or stolen. This may result in the loss of not only corporate information but any personal employee information stored on the phone as well.
Any requests for exception to this policy must be approved by AcmeGizmo’s IT security.
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.
Mobile Device Security For Dummies Page 12