Schedule periodic backups of your mobile device with your desktop, laptop, and/or remote servers.
For extended removable media, such as SD cards, ensure that these are backed up separately (in case your device backup software doesn’t do this automatically).
When the device needs to be restored to a previous known configuration, identify a known previous backup and initiate the restore procedure. This backup might be locally stored in your data center or with an outsourced service such as Carbonite.
As is evident, these are very generic policies, and the aim for you is to provide them as a rule of thumb. Your guidance can prompt your employees to capitalize on any additional bells and whistles that a particular device or OS vendor may provide.
For instance, Figure 4-7 shows a screenshot of the BlackBerry Protect application, which allows BlackBerry users to set backup options, including using the network interface they are on to decide whether to back up. Some users may be sensitive to the amount of data traversing the network during a backup operation, especially if they’re on a capped data-usage plan; therefore, the choice of backing up when the mobile device is on a wireless LAN and not backing up when the mobile device is connected to a 3G network, for instance, is very useful.
For the iPhone, the backup and restore application is built into iTunes. The user has little to do besides plug the iPhone into the computer regularly, and the backup happens automatically. Restore is also a very straightforward operation using iTunes. The user can open iTunes and select the Restore from Backup option shown in Figure 4-8.
For the Android, users have several options, including apps, service provider services, and connecting to a computer and working with folders in Windows Explorer. Also, some of the data (Gmail and other Google stuff) is automatically backed up in the cloud.
Figure 4-7: My BlackBerry Protect.
Figure 4-8: iPhone backup and restore capabilities.
Here are the key tenets for corporate-issued mobile device backup and restore policies that you would convey to users at your company:
The data on your mobile device is automatically backed up when you connect to the network. This data includes any personal information you may store on the device.
Tampering or interfering with this backup may result in confiscation of the mobile device.
Notify the IT department right away if your device is lost or stolen.
The use of removable media is highly discouraged. As the name suggests, the media can be removed and, therefore, cannot be guaranteed to be backed up.
Disabling or crippling the mobile device backup agent running on the device is prohibited and may result in confiscation of the mobile device.
For disaster recovery and multilevel backup of the storage servers that are used for mobile device data backup, the mobile device backup archives should be treated equivalently to the existing laptop and desktop backup server policies you have in place. You should not have to do anything significantly different as it relates to accommodating mobile device backups. In fact, the IT analysts at Enterprise Strategy Group conducted a survey in 2010 (shown in Figure 4-9), and found that the ability to integrate with existing backup systems for data protection ranked as the 10th most important consideration among IT executives when it came to evaluating, selecting, and implementing mobile security and management solutions.
Figure 4-9: Mobile device security priorities.
Using Provisioning Policies to Manage Devices
Provisioning policies are policies that define the lifecycle of mobile device management, including setting up the e-mail configuration, configuring backup and restore, activating the device with the service provider, maintaining compliance with enterprise guidelines, tracking inventory in real time, and decommissioning the device. Keep in mind that provisioning policies are predominantly applicable only to enterprise-issued mobile devices because these policies are about giving you control of the mobile device to do the management that you need to do.
For employee-owned mobile devices, there is no explicit provisioning that you need to be concerned about. Because the employee owns the device, the onus of activating, backing up and restoring, tracking a lost device, and so on rests with the user. However, you will need to provide a well-defined set of profile settings (network, e-mail, web, and security) that users can then use to self-provision their devices for connecting to the enterprise network.
Provisioning a mobile device typically involves the following three steps, as outlined in Figure 4-10 and discussed in more detail in the sections that follow:
1. Upgrade, downgrade, and install software.
2. Upgrade profile settings.
3. Decommission the mobile device.
Upgrade, downgrade, and software installation policies
Essentially, you use provisioning policies to change the software on mobile devices. And by the disruptive nature of these changes, you (luckily) do not have to deal with this on a frequent basis. When communicating with your users, you need to note that the software on their phones is subject to periodic upgrade and downgrade, and they need to know the following basic tenets of the policies:
As with any software update, there is a possibility that this may affect previous settings or cause stability issues; therefore, we highly recommend that you back up your phone prior to the upgrade or downgrade.
[Note that you are responsible for ensuring periodic backups of users’ mobile devices; however, it behooves your users to assume some responsibility toward this critical task, so we highly recommend reminding users to do this before a software upgrade.]
Figure 4-10: Types of provisioning policies.
In the case of manual upgrade or downgrade, we will notify you through e-mail, SMS (text message), or other means that an upgrade or downgrade is available and recommended. Please follow the steps outlined in that message to comply with the software change.
If we find that you haven’t performed the manual upgrade or downgrade after a period of # days [plug in your favorite tolerance window for your users in place of #] from when the notice was issued, your right to connect to the enterprise network may be curtailed.
In the case of automatic upgrade or downgrade, you will see a pop-up message when you connect to the network, and we recommend that you back up your device before proceeding with the change.
As in the case of manual upgrade or downgrade, if we find that you haven’t allowed the upgrade or downgrade after a period of # days [plug in your preferred tolerance window for your users in place of #] from when the pop-up message was posed, your right to connect to the enterprise network may be curtailed.
The IT department reserves the right to install new software at any time to your mobile device.
Similar to software upgrades or downgrades, additional software installation could be manual (you need to actively seek this software) or automatic (this will be pushed to you).
If we find that you haven’t performed the software installation after a period of # days [plug in your preferred tolerance window for your users in place of #] from when the new software notice was issued, your right to connect to the enterprise network may be curtailed.
Installation of unapproved software on the mobile device is not permitted. If such unapproved software is discovered, you will see a warning; after a period of # days [plug in your preferred tolerance window for your users instead of #] from when the warning was issued, if you have not removed the unapproved software, your right to connect to the enterprise network may be curtailed.
Profile settings policies
The profile settings policies that we discuss here are fundamental configuration settings that need to be provisioned on the mobile devices in order to get them to function per enterprise guidelines. Typically, these refer to web, e-mail, network, and generic security settings on the mobile devices.
Akin to the backup and restore policies that we discuss earlier in the chapter, profile settings policies are broadly classified into emp
loyee-owned and corporate-issued profile policies. The fundamental difference between the two — stating the obvious here — is that the former is the onus of the employee to configure based on the settings you provide, while the latter is provisioned by you before the device is handed to the employee.
The employee configuration of profiles isn’t as onerous as it sounds. In fact, the leading mobile device vendors have made this process very intuitive, and as long as you provide employees with the correct parameters, the configuration is a very straightforward task.
The following list describes some of the configuration profiles that you can create with the iPhone:
The iPhone e-mail configuration profile, shown in Figure 4-11, is fairly straightforward, and an average user would be able to configure it with ease using the relevant pieces of information: mail server address, port, username, and password.
The iPhone passcode profile, shown in Figure 4-12, is a tool that you can use effectively to mandate strict passcode parameters, using alphanumeric values as opposed to numeric only, longer passcode lengths, quicker passcode ageing, auto-lock with inactivity detect, and so on.
The iPhone VPN profile, shown in Figure 4-13, again follows typical industry terminology, and any users who have configured VPN on their laptops for home use should be able to follow the same logic easily on their iPhones.
Figure 4-11: iPhone e-mail profile.
Figure 4-12: iPhone passcode profile.
Figure 4-13: iPhone VPN profile.
To educate the end user about mobile device policies in the enterprise, you can use the following policy guidelines, which are directed toward your end users:
You’re required to use the recommended passcode policies on the device for basic device access security. You need to specify passcode length, duration, and patterns.
You need to adhere to the VPN configurations, as defined in the enterprise mobile device configuration guide [your published guide], in order to gain access to the enterprise network.
[If encryption strength (64 bit, 128 bit, and so on) is well-defined, you are protected against substandard VPN implementations.]
You are required to set up the mail access configurations, as defined in the enterprise mobile device configuration guide [your published guide], in order to connect to the enterprise mail server to access your corporate e-mail.
You are required to adhere to the web access policies, as defined in the enterprise mobile device configuration guide [your published guide], in order to gain access to the web.
The following user guideline applies to enterprise-issued mobile devices only; this cannot be mandated on employee-owned mobile devices:
You are hereby being made aware that certain functions of the mobile device may be restricted when the device is connected to the enterprise network. These functions may include using the camera, installing custom applications, capturing screenshots, using external storage, and so on. Any subversions to these mandated policies could result in rescinding your rights to connect to the enterprise network.
Decommissioning policies
This section applies only to enterprise-issued mobile devices.
You may be called upon to decommission mobile devices for one of these two reasons:
Accidental loss or theft of the device
Willful violation of mobile device policies
In either of the preceding cases, the steps that need to be taken are similar. Therefore, the policies that you define for decommissioning mobile devices should also be consistent.
You can use the following guidelines to educate end users about decommissioning policies in the enterprise:
You are expected to inform the IT department immediately upon loss or theft of your mobile device.
Your device will be located and locked out, and all data will be erased as soon as possible.
Any data loss as a result of the wipeout of the mobile device is your responsibility. IT does periodic backups; however, you are expected to follow the backup policies as well, especially if your device contains personal content, such as photos, music, and videos, for which the IT department bears no responsibility. Having a backup would allow you to quickly restore the configuration on a replacement phone.
If the decommissioning is a result of policy violations, a replacement phone will not be provided to you. Furthermore, if you owned the device and violated policy, access to the enterprise network and its resources will be prohibited for up to a year. [Change this based on your leniency threshold.]
BlackBerry in particular has had the remote-wipe feature for years, and some of the newer mobile devices have this capability. iPhone owners can remote-wipe their device through the subscription-based MobileMe services. Additionally, Apple now provides the Find My iPhone app (shown in Figure 4-14) free of charge. It can run on any iOS 4.2 device (or newer), including iPhone 4, iPad, and the fourth-generation iPod touch. In the event of a loss or theft (or maybe just for the heck of it), individual users now have the power to remotely locate and wipe out their devices. While these capabilities certainly sound handy, it does not take away your responsibility toward protecting the enterprise assets.
Figure 4-14: The Find my iPhone and Remote Wipe services.
Creating Effective Monitoring Policies
Monitoring policies have for the longest time been veiled under shrouds of secrecy so that employees are not quite aware of how, why, and when their actions are being monitored, and the IT departments — read you — have also not been explicit and forthcoming about exactly what is being monitored and what policies govern the use of the data that is captured. It’s time that we expose both the policies and governance models for the monitoring that you undertake so that everyone is keenly aware of them.
Unlike the device-based policies, which clearly distinguish between policies for employee-owned mobile devices and enterprise-issued mobile devices, monitoring policies are uniformly applicable toward all mobile devices regardless of their origin. The reason for this is once the mobile device connects to the network, it is incumbent upon you to be able to guarantee the security and integrity of the enterprise network and its assets. Therefore you need to do the monitoring agnostic of the type of mobile device.
Obviously, you have additional tools at your disposal for monitoring enterprise-issued mobile devices because you have local agents on the mobile device itself that you can exploit to gather this information. However, in the case of employee-owned mobile devices, you need to rely on the network exclusively to provide for monitoring capabilities.
To further muddy the waters, unscrupulous applications that employees download sometimes surreptitiously monitor detailed mobile device activity and sell it to advertisers and other scavengers. Once this is exposed, employees are extremely wary of any such monitoring apps, and you need to be all the more transparent in order to comply with your enterprise policies. In fact, a research project called TaintDroid (developed by researchers at Duke University and Penn State University) gives more power to advanced Android users by allowing this application to run in the background and alert users if any applications on their mobile device are shipping off their private information to a remote location, as shown in Figure 4-15.
Figure 4-15: The TaintDroid application.
It is expected that more commercial tools will be developed that will allow users to take back control of their mobile devices, or at the very least, be made aware of any applications that are spying. Your job is to spy on your employees with a goal of keeping them compliant, so in effect, you should be doing what projects such as TaintDroid are doing on the mobile device: keeping tabs on everything that applications are doing and intervening where necessary.
You can use the following guide to educate your end users about the monitoring policies:
All your activity when connected to the enterprise network will be monitored. This includes all enterprise applications as well as personal applications.
Any data collected during the monito
ring may be archived.
Any willful obstruction of such monitoring may result in revocation of connectivity rights to the enterprise network.
Purposely obfuscating data with the express intent of bypassing such monitoring is expressly prohibited.
The following guideline applies to enterprise-issued mobile devices only; this cannot be mandated on employee-owned mobile devices:
Even when the mobile device is offline (not connected to the network), it may still be monitored.
Because Android is an open environment where applications can be developed and marketed with little or no oversight by Google (as compared to the iTunes applications that Apple oversees closely), it is to be expected that a more fertile ecosystem of applications will thrive; some of them will give the user great control and visibility, the TaintDroid project being one example. In other less-open environments, like the iPhone or the Blackberry, it is far less likely that you can find monitoring applications that provide this level of scrutiny. However, where there is demand — in the form of users who are willing to pay for this level of scrutiny and take back control of their devices from opaque applications — there will be supply, so keep your eyes and ears open as these tools become available.
Protecting Devices with Application Policies
Application policies outline what applications users are permitted to use while accessing the enterprise network. Application policies are particularly crucial because the plethora of applications that users are able to download from mobile device vendors’ websites, carrier application portals, and independent third parties is multiplying exponentially, as you can see in the chart shown in Figure 4-16. Your users are likely to innocently download a malicious application that causes havoc both to the user and, more to the point, the enterprise network.
Mobile Device Security For Dummies Page 11