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.
Chapter 6
Con
forming to Corporate Compliance Policies
In This Chapter
Differentiating between personal and corporate-owned devices
Determining the device types or platform versions you will allow into your network
Defining passcode policies
Setting device encryption policies
Setting VPN and access control policies
Protecting smartphones from viruses, malware, and other mobile threats
Enforcing loss and theft protection on every device
Managing the devices centrally from a single management console
Creating a plan to regularly back up and synchronize device contents
Monitoring, inspecting, and controlling the data and apps that reside on smartphones
Many employees bring their personal smartphones to work and ask IT for help setting up VPN access. Often, corporate executives purchase the hottest devices on the market and want to use them at work. This is a change from a few years ago, when only corporate-approved devices — usually BlackBerry devices — were used to send and receive corporate e-mails.
This influx of new devices brings interesting challenges to both the device users and IT administrators. Enabling secure access on the latest devices necessitates creating policies that allow users flexibility without compromising the security of your network, and then enforcing those policies. The policies should be flexible enough to keep pace with the technology and plethora of new devices hitting the market.
In today’s world of increased mobility, the issue of enforcing corporate compliance on mobile devices is more critical than ever before. This chapter discusses the process of designing corporate compliance policies. We show you what it takes to allow smartphones and other devices to be granted access to corporate data and applications, while ensuring that they adhere to certain corporate compliance policies. We also give you an example corporate compliance policy comprising various rules and policies to be enforced on smartphones.
Which Devices Are Personal, and Which Are Corporate-Owned
Most companies have a combination of personal and corporate-owned mobile devices being used within their work environments. Many employees still carry their corporate-assigned BlackBerry devices to work, for checking e-mail. Others employees have abandoned their corporate devices and purchased their own iPhone, iPad, or Android device (or all of the above).
The foremost decision for corporate compliance should be whether a device is personal or corporate-owned. For personal devices, one set of policies should be enforced, and for corporate devices, another set of policies should be enforced. Enterprises look to deploy a set of enterprise apps onto corporate-owned devices and lock down the configuration of the device to the extent the device operating system allows. Locking down corporate devices may include preventing access to certain utilities like the app store. With personal devices, enterprises typically cannot lock them down to the same extent. The priority for personal devices is to ensure that the devices connecting to the corporate network are protected from malware, viruses, and other threats. Enterprises also seek to deploy a sandboxed environment for their corporate applications so they’re shielded from the rest of the personal data on the device.
For corporate-owned BlackBerry devices, most IT departments have infrastructure or applications installed that manage critical policy enforcements. For example, the BlackBerry Enterprise Server manages policies for BlackBerry devices, which is the reason why those devices are often the corporate standard. For employees’ personal devices, however, it’s difficult for IT to enforce the same set of policies on the devices, which may differ in device type, operating system, version, and vendor type. Therefore, we recommend classifying personal devices into one category and enforcing one set of policies for them, which may or may not match the policies enforced on corporate devices.
Personal devices are purchased by the employees themselves, and therefore, employees expect a greater degree of flexibility and less employer control than on corporate devices. You can expect personal devices to have the employee’s personal content, including photos, videos, SMS messages, and other private data.
Now let’s look at what policies you want to enforce on each category of devices. Here’s how your classification of devices may look:
Personal devices allowed for corporate access:
• Android devices running Android version 2.1 or later (like the HTC Desire and Samsung Nexus S)
• Nokia E7 and other phones running Symbian 3
• Apple iPhone 3GS, iPhone 4, and iPad running iOS 4.0 or later
Corporate-assigned devices allowed for corporate access:
• BlackBerry (all models)
Devices that are not allowed into the corporate network:
• Android devices running Android version 2.0 or earlier
• Windows Phone 7 devices
Of course, your policy may look different from this example. Choosing devices to allow into your corporate network depends largely on your tolerance for risk and device heterogeneity. So make sure to research the latest smartphone platforms available today and determine which ones you might allow into your network.
From a compliance perspective, we recommend rejecting jailbroken or rooted devices from entering your network, and stating that in your policies. The risks posed by such devices to your corporate network far outweigh the flexibility of users being able to install private apps, outside of the application stores. Also, such devices are unsupported by the device vendors, so any issues with the phones will not be resolved by the vendors. For more information on jailbroken or rooted devices, see Chapter 2.
Setting Passcodes on Mobile Devices
Setting passcodes on mobile devices is the most basic security requirement for any smartphone to be allowed into a work environment. Passcodes require the user to enter a passphrase to unlock the phone. Devices can also be configured to lock automatically after a configurable timeout period. (Typically, five minutes is ideal.)
From a compliance perspective, take a look at the passcode policies that you may want to enforce on smartphones:
The device needs a passcode configured.
The passcode needs to be of a certain strength, incorporating at least one digit or complex character.
The passcode needs to expire after a certain time period.
The device should lock after a certain time period of inactivity.
Some sort of action should be taken if the threshold for failed attempts to enter the right password (such as ten consecutive bad passcodes entered) is reached.
For different organizations, the exact passcode requirements will vary. For many, it might suffice to simply require a passcode on each smartphone in the corporate network. For others, it might be necessary to enforce additional restrictions, such as the passcode strength and expiry time period. What you specify for your organization’s passcode requirements largely depends on your tolerance for risk and adherence to other corporate policies or restrictions.
At this time, you also need to decide whether to enforce the same set of passcode policies on both personal devices and corporate-owned devices. As we explain earlier in the chapter, you have the liberty to define different compliance policies for corporate-owned and personal devices and establish different passcode policies for the two categories of devices.
Tables 6-1 and 6-2 summarize what a portion of the compliance policy might look like.
Encrypting the Contents of the Device
Data encryption prevents sensitive smartphone data from being accessed without entering the device owner’s passphrase or secret key. Encryption refers to the process by which vital data is made inaccessible to users who don’t know a secret phrase or password. For example, the passphrase used to lock the phone could be used as a password to encrypt the data on the device.
Typically, smartphones are used within the workplace to access corporate e-mail, browse intranet web pages, or even access client-server applications like O
racle or SAP. In addition, the devices may also store contacts, SMS messages, or files related to work.
From a compliance perspective, encryption of the device should require such content to be encrypted before being allowed into the corporate network. Here’s a list of the types of data that should be encrypted on the device, at a minimum:
E-mail
SMS messages
Contacts
Calendar
SD card contents, which may include files of various types
The challenge in requiring encryption to be enabled on smartphones is that not all smartphones support hardware encryption. For example, the Apple iPhones and iPads support it on devices running version 4.0 or later, but not on earlier versions. Android devices don’t have encryption capabilities, at the time of writing this book.
The specific policies for data encryption will vary for different organizations, depending on each organization’s tolerance for risk and the importance of this particular form of security.
At this time, you should also decide whether to enforce your encryption policy on both personal and corporate-owned devices. Ideally, you’d want to do so, thereby ensuring that the policies are consistent for all devices in the corporate network. However, because some devices (we’re looking at you, Android) don’t currently support encryption, you will need to decide whether to let some devices into your network without encryption, or enforce encryption as a policy throughout the smartphone network, thereby denying access to some popular Android devices today.
Mobile Device Security For Dummies Page 15