6. Connect the new BlackBerry device to proceed.
This procedure enables you to transfer not only data such as SMS messages, contacts, and call logs, but also apps from one BlackBerry to another.
Transferring data between Nokia Symbian devices
Nokia Symbian devices have a program called Switch that enables you to transfer data and apps from one device to another, or keep two Symbian devices in sync.
Follow these steps to transfer data from an old Symbian device to a new one:
1. Start the Switch option by choosing Menu⇒Settings⇒Connectivity⇒Data Transfer⇒Switch.
2. Set a connection type to the appropriate method.
For example, if both devices support Bluetooth, select it as the method to connect them.
3. Connect the two devices by entering a code on both devices.
Entering the same code on both devices allows them to be paired.
4. On the new Symbian device, select the content to be transferred from the other device.
The transfer of data proceeds, transferring the information you selected from the old device to the new one.
Exploring Corporate Solutions for Backup and Restore
The options for backing up and restoring data vary from one device to another. Most OS and device vendors offer software applications to facilitate the backup and restore features on their own devices. For example, the iTunes software facilitates backup and restore only for iPhones and iPads. Likewise, the Nokia PC Suite can back up and restore data only for Nokia Symbian smartphones. It’s the same story with the BlackBerry Desktop Manager, which works only for BlackBerry devices.
If you’re looking to deploy backup and restore for your employees, you’re probably alarmed at the prospect of managing so many different applications. Gone are the days when everyone had a BlackBerry smartphone and all you needed to do was install and maintain the BlackBerry Enterprise Server. Now, people use a wide variety of devices, including the popular iPhones and iPads and the increasingly popular Android devices.
It’s clearly an administrative nightmare to handle each device with its own unique software application. What you need is an application that can back up data from different types of devices and restore to devices of all those types as well.
There are solutions available from vendors to manage mobile device policies, including backup and restore for all leading smartphone types. They’re generally called mobile device management (MDM) solutions. Chapter 15 offers a detailed discussion of solutions for mobile security and device management.
Table 12-1 provides a checklist of things to look for when you’re short-listing MDM solutions for deploying backup and restore to your company users.
Case Study: AcmeGizmo Backup and Restore Use Cases
Over time, Ivan, the administrator, had become quite comfortable with the mobile device security solutions that he was responsible for rolling out across AcmeGizmo. One afternoon, the deployment was really put to the test. Pete, the President and CEO of AcmeGizmo, had apparently lost his Windows Mobile smartphone somewhere between his home and the airport.
Prior to the deployment of the current security and device-management products, Pete might have risked losing all his data when he misplaced his smartphone. As an end user, his primary option for backing up data from the device would have been to synchronize the device to his PC using the Microsoft Zune desktop software. Unfortunately, it had been over a month since Pete had done so — busy executives often don’t consider smartphone backup a day-by-day top priority. Ivan would later inform Pete that he could set his Zune device to back up to his PC automatically, but Pete hadn’t done that prior to this loss. The damage was done.
Luckily, Ivan had implemented backup and restore functionality for AcmeGizmo, and Pete’s phone was covered. Although this software didn’t back up Pete’s applications, the core of the most important data on the device had been backed up.
The first thing Ivan did was to remotely wipe the lost device, ensuring that the sensitive corporate data on the device wouldn’t end up in the wrong hands. Having settled that issue, Ivan remembered that he had a new Android smartphone that he had been using for internal testing back in his office. Knowing that it was critical for Pete to get up and running quickly, he offered Pete the Android device.
Because the backup and restore solution that Ivan had chosen for AcmeGizmo was able to store device settings in a device-independent fashion, Ivan could take some of the backed-up files from Pete’s Windows device and restore them directly to the Android device. Eventually, Pete ordered a new Windows device and could restore everything — with the exception of applications, which Windows doesn’t back up.
It could have been so much worse.
Chapter 13
Securing Mobile Applications
In This Chapter
Recognizing the importance of sandboxing
Understanding how sandboxing works on various platforms
Protecting your network with virtualization
Thousands of applications are available in the marketplace or app stores for mobile devices, including iPhones, iPads, and Android devices. Whether you’re downloading apps from the market or deploying apps to your company’s employees for their devices, it’s important to know what security exists within these applications to protect them from other applications. Mobile operating systems like Apple iOS and Google Android have built-in security infrastructure protecting applications from each other.
Protecting or shielding one application from another is often called sandboxing. In effect, the application has its own little sandbox to play in and has no access to data or information stored in other applications’ sandboxes.
This chapter examines what sandboxing means for the corporate environment when employees bring their personal phones and tablets (and whatever’s on them) into the workplace. It’s desirable for the enterprise to deploy security in a way that shields the applications on its employees’ mobile devices from one another. The idea is to prevent accidental leakage of corporate information or even theft by a malicious application.
Understanding the Importance of a Sandbox
A sandbox is an environment in which each application on a mobile device is allowed to store its information, files, and data securely and protected from other applications. The sandbox forms and maintains a private environment of data and information for each app.
Keep in mind that a sandbox does not make the entire device any safer. If a malicious app is downloaded to the device, it can still infect and steal information from the user directly, even if not from another application. For example, if a simple gaming app downloaded from the Internet asks the user for access to GPS information, that’s cause for suspicion. Hackers write apps that seek information directly from unassuming users, and some can assume the guise of a simple and uncomplicated purpose (as with a gaming or utility app).
As an analogy, think about the various applications on a PC: browsers, text editors, and other such everyday applications. A sandbox would make each application write its data into a particular folder that would be inaccessible to other applications. Although this would mean that a virus couldn’t access users’ e-mails or read a folder maintained by their Word applications, the malware could still cause trouble, stealing other device-specific information or prompting users for credentials. Having a sandbox is therefore not a substitute for having antimalware applications.
Here are the main points to keep in mind about sandboxing mobile applications:
Apps can be sandboxed. Apps can be developed to protect their information and data from each other, preventing one app’s data from being read by another app.
A sandbox does not equal mobile security. Sandboxing one or more apps means only that those apps are shielded from each other. Malicious apps can still be downloaded that seek information from unprotected apps or directly from the user.
A sandbox does not protect the entire device. To protect the entire
device, you need a mobile security app that detects and prevents viruses, spam, Trojans, and other mobile threats from invading in the first place. Chapter 10 describes such threats and their prevention in more detail.
All mobile apps maintain a lot of application-specific information, often stored in files on the mobile device file system. Depending on the application type, the information may include personal or corporate information, which in turn might include confidential or sensitive information. With the prevalence of mobile banking, corporate access, and other such use of smartphones, the information stored by each app is valuable. It’s therefore imperative to ensure the safety and security of the data stored by each app.
App Security on Various Platforms
Many enterprises develop their own mobile applications for various platforms, including the BlackBerry, Apple iOS, and Google Android. Some also develop applications for Nokia Symbian and Windows Mobile or Phone platforms. If you are an administrator wanting to deploy your own apps to employees, you should be planning for securing the contents of corporate-owned apps, as well as for protecting the contents of such apps from other third-party apps on the device.
As we mention earlier, sandboxing or securing an app’s data from other apps is available on several platforms. In the following sections, we take a look at how app security is accomplished on the three leading platforms enterprises deploy: the BlackBerry, Apple iOS, and Google Android.
App security on BlackBerry devices
As an enterprise administrator, you can control what apps can be deployed on your employees’ BlackBerry devices. The BlackBerry Enterprise Server (BES) is an example of a leading Mobile Device Management solution for BlackBerry devices that allows the configuration and enforcement of several application security policies for corporate use. Using BES policies, you can specify whether a user can install third-party apps, or determine the privileges that third-party apps can enjoy on the device.
Third-party apps can, in general, access two types of data on a BlackBerry device:
User data, such as e-mail, calendar, and contacts
App data — persistent storage that shares data with other applications
You can control or restrict access to both types of data by using BES policies. If you develop your own apps for corporate-owned BlackBerry devices, you can enable appropriate permissions for your apps.
The BlackBerry also includes a personal firewall feature that restricts the types of connections maintained by an application. When an app tries to establish an internal connection to a corporate server, the device prompts the user to allow or deny that connection. As an administrator, you can choose to allow or deny such connections as a policy. This prevents suspicious apps from breaking into your corporate network and stealing information from internal servers.
Third-party apps can be written to use BlackBerry device APIs for sensitive packages, classes, or methods. Such apps need to be signed by Research in Motion (RIM) before they are allowed to use those APIs. The signing process ensures that the app is tested and verified for authenticity before being granted APIs to use sensitive information.
App sandboxing on Apple iOS devices
Application developers use the sandboxing capability of Apple iOS to protect the integrity of user data and to ensure that their applications don’t share data with other apps installed on the user’s device. Each app has access to its own files, preferences, and network resources. Recent versions of iOS have also added the capability to encrypt application data so that sensitive data such as usernames, passwords, or credit card numbers can’t be accessed easily from the file system.
A sandbox limits the damage that a potential hacker can do to an Apple iOS device, but it cannot prevent an attack from happening. Software defects in an application could allow a hacker to cause the app to crash. Although Apple has built robust sandboxing features into the Apple iOS, it’s up to the app developers to ensure that their apps are written securely and to prevent hackers from exploiting user data.
When an app is installed on a mobile device, the system creates a unique folder for it, much like you would do on a regular computer. The path to the app’s home directory looks like this:
/ApplicationRoot/ApplicationID/
The ApplicationRoot folder is where all apps are installed. The ApplicationID is a unique name for each app, and distinctly identifies the app to set it apart from other apps. Each app stores user data and configurations within this folder.
Each app’s folder is protected and shielded from access by other apps, as shown in Figure 13-1.
Figure 13-1: Application directories and separation on an Apple iOS device.
Protecting files on iOS devices
On Apple iOS devices, certain files marked by the app developers can even be encrypted when the device is locked. Doing so requires the encryption capability of the device to be enabled and configured. Once that’s done, certain types of content can be protected automatically when the device is locked. When the files are locked, not even the app can access their contents.
This feature also extends the protection that shields a particular app’s data from another app. Note, however, that this is an optional feature; not all apps need to encrypt files on the file system. A file only gets encrypted if the app developer designates it for automatic protection. Even so, this is a useful feature for app developers, especially if they hold sensitive information on the device (such as the user’s username, password, or other credentials).
Sandboxing your apps on Apple iOS devices
If you’re in the process of buying apps — whether for your company’s employees or for yourself — you’d be well advised to check each app’s security capabilities. As noted earlier, some capabilities (such as file encryption) are optional and used at the discretion of the app developer. Therefore, it’s worth asking those app developers about the security capabilities of the apps.
If you’re considering writing apps for iOS, the native capabilities of iOS allow you to build security within the app itself. For more information about how to develop security within your app, consult the Apple iOS developer documentation.
If you want to deploy corporate apps for your employees’ Apple iOS devices, look for Mobile Device Management capabilities that will enable you to set policies governing the use of third-party apps on those devices. Chapter 15 lists the key vendors providing such MDM solutions, many for Apple iOS devices. Be sure to check out those solutions for your specific needs.
Android operating system security
Like the Apple iOS platform, Android has a number of security features built into its operating system. On Android, by default, no application has the permissions needed to perform operations that impact other apps, or, for that matter, the device in general. This arrangement prevents apps from reading information or data stored by other apps, and keeps them from reading the user’s personal data (such as contacts and e-mails) stored on the device. This inherent security model forms the basis of the Android operating system.
For one application to share data with any other, it must give explicit permission to the other app to read its data. For example, suppose an app that a user downloads from the Android Market needs permission to know her GPS location — say, an app that shows local restaurants and has to know where the user and her device are in order to do its work. When the user installs such an app, it prompts her for permission to read her GPS location. If she grants it that permission, the app will deliver its GPS-dependent features and won’t prompt her for permission later, when she runs it.
Android is based on the Linux Operating System, which has elaborate security mechanisms built in. Each app runs with a distinct system identity (including its Linux User ID and Group name), which is unique for all apps. The Android OS assigns a unique User ID to an app when the app is installed. Linux uses this mechanism to separate apps from each other and protect the system in general.
Even with the security built into the Android OS,
users own the ultimate responsibility for protecting their devices. A malicious app in the Android Market could still be written to seek permission to a user’s SMS messages, contacts, or GPS location. The security built into the OS protects apps from one another, but does not necessarily shield the user’s data from malicious apps. So this security feature is only one piece of the puzzle; it does not preclude the need for mobile security on the Android device.
Be sure to check out the solutions and vendors discussed in Chapter 15. Many of those solutions allow you to configure and enforce corporate compliance policies governing the use of third-party applications on Google Android devices. Depending on your specific needs, one or more of those solutions may be interesting to you.
Exploring Virtualization for Mobile Devices
At a VMWorld conference in 2009, VMWare announced that it was working on building virtualization for mobile devices, which would allow multiple operating systems to run on a single device. In virtualization lingo, this means a guest VM would run on a mobile device, separate and potentially different from the base OS (the OS that comes with the device). Today, when handset vendors release mobile devices, their products use specific operating systems and are identified as Windows Phone 7 devices, Nokia Symbian devices, Android devices, and so on. For that matter, Apple’s devices (such as iPhones and iPads) run the Apple iOS platform as the base OS.
The prospect of running multiple operating systems on a single device brings about interesting possibilities. A VM is probably as good as any sandbox could get, completely virtualizing and separating system and device resources from one VM to another. This capability would be especially attractive for work environments; mobile devices could be virtualized in much the same way computers and servers are virtualized presently. Virtualization of servers and desktop computers would allow multiple operating systems (say, Windows and Linux) to run on the same device. Sound too good to be true? Unfortunately, it is — for now.
Mobile Device Security For Dummies Page 29