DUE TO THE IMMENSE POPULARITY of smartphones and smart devices, and to the very lucrative potential of gains in market share, each of the major smartphone vendors—Google, Apple, and Microsoft—has adopted an approach to improve security and lower risk for users. Interestingly, these vendors’ approaches don’t significantly differ. All three are based in part on the two main concepts of controlling access to applications (downloads) and compartmentalizing applications and their resources once downloaded.

Recent years have also seen a push to ensure that mobile platforms are well suited for use in enterprise settings, given the growth in acceptance of bring your own device (BYOD) policies. In response to this, mobile platforms are increasing their support of enterprise management security, monitoring, and control services that allow information technology (IT) teams to efficiently manage large numbers of mobile devices.

This chapter looks at the security models of each of the major mobile platforms—Google Android, Apple iOS, and Windows Phone. After reviewing the similarities and differences between these, the chapter then explores how IT organizations manage the security and control of smart devices on a large scale.

Google Android Security

The Android operating system (OS) is built on the Linux open source OS. However, the applications used on Android devices are developed in Java. In particular, Android uses the Dalvik Java platform. Developers typically write their apps in Java and then use the Google Android software development kit (SDK) tools to convert their applications to run on the proprietary Dalvik platform on all Android devices.

The Android security model is based on an open system. As an open system, Android allows owners to download applications and software from any Web site. Therefore, to fully benefit from Android’s security model, it is up to the owner to vet the trustworthiness of any download’s source.

The Android Security Model

Android is built on the Linux kernel, which has been used for many years in security-sensitive environments. Android applications use process sandboxing for security. This means that each Android application runs in its own Dalvik virtual machine (VM), and each VM is isolated within its own Linux process. Although the Java and Dalvik VMs are secure, Android does not rely on Java VM to enforce security. Instead, it looks to the Linux kernel. The Linux kernel is therefore the foundation for Android security and provides key security features. These include a user-based permission model, process sandboxing, extensive mechanisms for inter-process control, and the ability to remove unsecure elements of the kernel. This is made possible through Linux’s extensive multi-user features, which isolate and prevent User A from reading User B’s files, applications, resources, or memory. Android builds on these concepts to create what is known as the Android sandbox.

The Android Sandbox

Android takes advantage of Linux’s multi-user environment by adapting the multi-user–based protection as a means for identifying and isolating Android applications. The Android security system assigns a unique user ID to each Android application and then runs the application as a separate user process with its own permissions. This configuration isolates applications and their files, resources, devices, and memory. Furthermore, because the application kernel is within the OS kernel, this isolation extends to OS applications, libraries, application frameworks, and the application runtime.

One of the security benefits of application isolation within a sandbox is that not only are inter-process communications controlled, the resources and memory are as well. One benefit, for example, is that a memory crash in one application will not create a security issue that compromises the overall security of the device. In a sandbox environment, a memory crash will only allow arbitrary code to be executed within the confines of the affected application, and under the same permissions. That is, there is no leakage between applications when one crashes or is compromised.

File-System Permissions

Permissions are how the Linux file system ensures that one user cannot access the files of other users or, in the case of Android phones, how it prevents one application from accessing other applications. In Android, each application runs as a user with its own set of permissions. Unless a developer explicitly grants permission to expose files to other applications, files created by one application cannot be read or used by another application.

Android SDK Security Features

Notable features in the Android SDK make memory-corruption issues much harder to exploit. One of these features is ProPolice, which prevents stack overflows. There are also tools to protect against leaking kernel addresses and integer overflows during memory allocation. In addition, there are techniques for format string protection and a hardware-based “No-eXecute” parameter (control) to prevent code execution on the stack or heap.

Android can also encrypt data through cryptographic application programming interfaces (APIs), which support crypto primitives. These are low-level cryptographic algorithms used to build cryptographic protocols such as Advanced Encryption Standard (AES), RSA (an acronym of the last names of its developers, Ron Rivest, Adi Shamir, and Leonard Adelman), Digital Signature Algorithm (DSA), and Secure Hash Algorithm (SHA). Android 3.0 and later also support full file-system encryption where the encryption key is protected with AES-128 by a key derived from the user password. This protects the user’s data from unauthorized access.

Rooting and Unlocking Devices

In the Android security model, only the lowest layer, the OS kernel, and a small subset of the core applications run with root permissions. Root (super-user) permissions give a user or application unrestricted access to the operating system, kernel, and any application. Rooting a device gives someone privileged root permissions, enabling him or her to override the Android OS security and do anything on the device. Changing the permissions of an application to root, however, significantly increases the device’s vulnerability to malware. Unfortunately, some versions of Android enable the user to change the boot sequence through the boot loader, which enables him or her to upload an alternative version of the OS or an application with root permissions.

Android Permission Model

Android applications run in sandboxes. By default, these have only limited access to system resources. This approach restricts access to features and resources that may, if used maliciously or incorrectly, cause the device to be compromised. These restrictions are implemented by a variety of methods. Some are protected by a deliberate lack of an API. Others have protected API status. Only trusted applications can access these protected APIs, which are protected by a mechanism called permissions.

To use these APIs, an application must receive the permission of the device’s owner. This is done through a request for permission to access features and resources at the time of the application’s installation. These requests for permission are listed in the application manifest and are supplied to the user for inspection prior to installing the application. It is the owner’s responsibility to grant or deny permission to access certain protected features and to allow the application’s installation. After the user has given permission to the list of requests in the manifest, the application will be installed with those permissions.

The application will retain those permissions for as long as it remains installed. Although the owner can view and check the permissions for any application, he or she cannot revoke an installed application’s individual permissions. Permissions can be revoked or removed only when the application is uninstalled, although individual features can be globally turned off—for example, Bluetooth or Wi-Fi.

Another security concern with rooted Android devices is that Android natively supports active content such as Flash, Java, JavaScript, and HTML5. This can open attack routes for malware. Additionally, there are new features, such as Always on Listening and Auto Content Update, which can be vulnerable to misuse because they can dynamically enable or disable features, provide location information, or record conversations.

Apple iOS Security

The Apple iOS operating system is a slimmed-down version of Apple’s OS X operating system, which is used in the company’s line of Mac computers. OS X is actually a derivative of the FreeBSD variant of UNIX code maintained by a large open source community. Its security model is based on access control, application security, encryption, and isolation.

The Apple Security Model

Apple uses a walled garden approach to security, restricting access to and downloads from Web sites other than its own App Store. This focus on application provenance through its iOS Developer Program and iOS Developer Enterprise Program is to ensure that users can trust the authenticity and integrity of applications in the App Store. Those who produce apps must register and pay to become official iOS developers. When they do, they are given a digital certificate with which to sign their applications. Only digitally signed applications from authorized developers can be uploaded to the App Store. The digital certificate also ensures the integrity of each application, as the code cannot be tampered with after release. In addition, Apple’s application provenance requires developers who wish to publish consumer applications to distribute and sell through the Apple App Store. By doing so, Apple can police the quality and safety of each application submitted before supplying the certificate and posting it to the App Store.

Application Provenance

The application provenance approach employed by Apple does not guarantee that applications in the App Store are safe. It does, however, greatly increase the odds that application developers will be held accountable for their work. This can deter developers from publishing malicious code. That said, the certification process is not entirely foolproof. For example, a developer could use a stolen identity to register for an account and attempt to upload malicious applications (spyware or mobile adware).

Despite the possibility of spoofing, application provenance has proven to be a successful approach for Apple, judging by the lack of malware in the wild that targets non-jailbroken iOS devices (that is, those in which the user has not circumvented security features). There are several reasons for this:

•  Developers must register and pay to gain access to the App Store and obtain a digital certificate.

•  Apple thoroughly tests all applications for security and malware, and violations are likely to be identified. That means rogue developers will be identified, banned, and possibly prosecuted—a daunting prospect given Apple’s financial might and strong economic and technical leadership.

•  Apple’s digital certificate for approved products makes it impossible for cybercriminals to modify or tamper with released applications. That means hackers must create new applications rather than embed malware into existing code.

The main limitation of application provenance is that it works only on iOS devices that have not been jailbroken. If an owner jailbreaks his or her device to download apps from any other source, that person circumvents Apple’s application provenance model. Once the provenance model has been disabled, an iOS device is vulnerable to malware attacks.

iOS Sandbox

Apple also isolates applications by running each one in its own sandbox. As noted, a sandbox isolates an application’s data, resources, and services from other applications. Additionally, apps cannot determine whether other applications are even present on the device. Further isolation is achieved by preventing an application from gaining access to the OS kernel or from obtaining root privileges through the installation of drivers. This segregation approach provides a high level of separation between applications, and between applications and the OS kernel. The result is that the Apple iOS provides very strong protection from malware.

Apple’s sandbox vision differs from Android’s from a conceptual point of view. Apple allows applications free access to system resources and features. In contrast, Android requires the owner’s permission before access is granted to an application or system feature. With iOS, an application may access contacts and calendars in addition to music, phone, and video files. Similarly, iOS allows direct access to Safari search history, YouTube playlists, and the device’s microphone and video camera without the need for the owner’s permission. This, of course, has created privacy issues. Although Apple’s provenance approach has been praised, with regard to the handling of access to services, it has drawn criticism.

Security Concerns

Although applications are isolated from each other, they are still theoretically vulnerable to Web- or network-based attacks. For example, an attack on the device’s Safari Web browser via a malicious Web page could gain control of the browser’s logic—although because it could not spread to any other application, the attack would be contained. Nonetheless, the malicious payload—although segregated—is free to obtain system-wide access to the calendar, address book, and even the cameras. Moreover, it can steal any data that passes through the browser application, including Web passwords and login credentials.

That being said, ensuring that apps on the device cannot be modified by other apps limits the impact of malware and prevents acts such as loading drivers or rootkits into the kernel. Sandboxed applications also have restricted access to SMS and to the telephone function, which severely limits the potential effect of Trojans. Such forms of malware would have unrestricted access to the Internet, which could result in malicious data loss given the free access to contacts, addresses, and so on.

Permission-Based Access

The Apple iOS version of permission-based access control is built on a much more limited restriction list than Android’s. In iOS, an application requires an owner’s permission only when doing the following:

•  Accessing location data from the GPS

•  Receiving remote notification alerts from the Internet

•  Initiating an outgoing call

•  Sending an SMS or e-mail message

Besides being much more limited than Android’s extensive permission-based control of system resources, this permission model is longer lasting as well. For example, if the owner of a device grants a Global Positioning System (GPS) application permission to access location-based features, then that permission is granted permanently. This need for permission is similar to the Android model, but different. With Android permissions, a request is required every time an application attempts to initiate a call or send an SMS or e-mail. In contrast, with Apple, the request is made once and not required again. This is great from a convenience standpoint but it does lead to a higher risk of abuse because few people read all the fine print when accepting a user agreement. This can lead to users inadvertently granting permission to services that they might not allow, not realizing those permissions are excessive.

Encryption

Apple relies on more than application provenance, isolation, and strong access control. It also provides a high level of protection through full-device encryption. However, Apple’s implementation of full encryption requires that a key reside on the device. That’s because it continuously runs apps and services in the background, even when the user is not logged into the device. Therefore, data encrypted with this technique would be readable to someone with physical access to the phone, even if he or she did not know the user password. To mitigate this, iOS uses a layered approach, with certain data—typically e-mail files and messages and other personal data—double encrypted. Layering the encryption in this manner secures the files from unauthorized access. Only someone with the master pass key can read the data.

Jailbreaking iOS

Apple iOS security measures are, by design, restrictive, and are robustly enforced by Apple’s security strategy. Many owners have found this too restrictive, however. They want to download their own applications without interference from Apple. Jailbreaking, or unlocking the device, has become a popular way to free the device so it could be used to download applications from any source. Jailbreaking is also used by those who wish to unlock carrier restrictions, which bind carrier-subsidized phones to the carrier networks.

Jailbreaking the device gives owners root (super-user) privileges. This enables them to override the application provenance model, which is the foundation of the iOS security framework. By jailbreaking a device, owners can download applications, music, and content from wherever they like. Unfortunately, this freedom comes at the cost of security, undermining the layers of protection behind Apple’s walled garden security strategy. One would assume that users capable of successfully jailbreaking a phone would know enough to protect against malware, but given the ease with which cookbook-type instructions can be found and followed, many users get in over their heads.

Windows Phone 8 Security

Windows Phone 8.1 is the latest version of the Microsoft smartphone OS. With the 8.1 release, Microsoft has pursued corporate acceptance with features that provide security and management control, mitigate data leakage, and offer protection from malware. Microsoft has also integrated security features such as BitLocker, Windows Defender, SmartScreen Filter, and user access control into the security architecture for its mobile devices.

Platform Application Security

Microsoft’s strategy is to protect applications through isolation. Like Apple iOS, Windows Phone uses strict application provenance. Consequently, Microsoft has adopted the secure App Store model, naming its version the Windows Store. It follows the same basic model, whereby only strictly vetted applications are released and downloaded to devices running Windows Phone 8 (WP8).

Security Features

Security features in the current WP8 OS include the following:

•  Unified Extensible Firmware Interface (UEFI)—This standard firmware interface was designed to eventually replace BIOS, the old Basic Input/Output System used on IBM-compatible personal computers. UEFI provides the same functionality, initializing hardware and starting the boot loader, but also ensures that the OS loader is secure and tamper free. This deters users from jailbreaking the device. As with iOS, jailbreaking severely hampers the task of securing the device by allowing the installation of unauthorized applications and potentially malware.

•  Trusted Platform Module (TPM)—TPM is a crypto-processor designed to secure data, enable authentication, and ensure device integrity.

•  Data Execution Prevention (DEP)—This is a defense technology that aims to reduce the attack surface area for memory-related exploits.

•  Address space layout randomization (ASLR)—ASLR protects the system by moving executable images into random areas of memory. This makes it very hard for an attacker to exploit vulnerabilities in applications.

•  Device encryption—All Windows Phone devices support device-level encryption based on the BitLocker encryption technology.

•  AppContainer—This is sandboxing technology for applying fine-grained security permissions and blocking unauthorized access to the system, applications, and data.

•  SmartScreen Filter—This is a mechanism to prevent phishing attacks. If SmartScreen detects malicious content on a Web site, it warns the user and blocks the site or specific content on the Web page.

•  Apps and programming architecture—The application’s architecture is similar across all Windows platforms. This allows developers to write an application just once to make it available across all Windows devices.

•  Remote business data removal—This is one of the many mobile device management (MDM) features introduced to make Windows a business-class OS.

•  Virtual smart cards—These provide two-factor authentication, allowing for stronger authentication than simply usernames and passwords.

One of the advantages of Windows Phone 8 is that its security policy and control can be enforced on any Windows Phone device, providing a standard level of security across all platforms. This is in sharp contrast to Android, which is fragmented and used over a diverse range of products. These products use different features and controls, making it difficult to apply a uniform security policy across all devices.

Secure Boot

When a Windows Phone device starts, it first looks to the firmware to initialize the hardware and then loads the boot process. The boot process will only start, however, if the boot loader is a trusted authority—one that is registered in the UEFI database and has a signed digital certificate. With Windows Phone 8 devices, this determination is made by Secure Boot. Once Secure Boot has verified the boot loader, a Trusted Boot process begins. This is a sequence in which each component is checked and verified for integrity and tamper-free code before being loaded. For example, the boot loader verifies and checks the digital certificate of the Windows Phone system kernel, which is loaded only if the check passes. The kernel then checks the digital certificates of all the other components before loading them. Trusted Boot will load a component only if it is trusted and has passed the digital certificate check.

System App Integrity

After the Trusted Boot process is complete, the system commences loading applications required at startup. Again, only signed applications can be started and loaded. Therefore, every application on a Windows Phone 8 device must have a digital certificate. This requirement is enforced via a policy that requires every genuine Windows app be signed. Consumer apps are available only through the Windows Store (where every app must have a certificate). For business apps distributed through an enterprise, the company must use its enterprise developer certificate to sign its own in-house applications.

Securing Apps

Securing the OS through the Trusted Boot chain is only the first stage in providing a defense-in-depth approach to Windows Phone devices. The second stage is to compartmentalize apps and their environments and resources. This is another sandboxing technique whereby Microsoft uses different levels of chambers to host applications that have differing security levels and requirements to access system capabilities. System capabilities include features such as GPS, cameras, and networking. These capabilities are defined by their potential to have a cost, privacy threat, business concern, or security issue that requires protection. Therefore, the security policy of each chamber defines which capabilities each app can access. In addition, each chamber has a configurable isolation boundary that prevents apps from communicating with apps in other chambers.

Windows Phone Security Issues

Windows Phone 8 appears to be the most secure operating system on the market. At the time of this writing, there are no identified public vulnerabilities. Windows Phone has integrated several key technologies into its devices for added protection, such as BitLocker, Windows Defender (anti-malware software), SmartScreen Filter, and AppContainer (sandbox). BitLocker, which provides the important function of full-device encryption, works only with a Microsoft Exchange Active Sync connection, and is not available directly to consumers. This would indicate that data locations are unprotected. Without jailbreaking the phone, however, they are difficult to access—and jailbreaking the phone requires physical access.

Security Challenges of Handoff-Type Features

In 2014, Apple released a new feature, called Handoff, with Windows and Google working on similar technology. Handoff allows users to move seamlessly between devices, continuing right where they left off when they switch devices. So if, for example, a user is interrupted while composing an e-mail on a Mac, that user can switch to another device—say, an iPhone—and continue where he or she left off. The same would apply to browsing on an iPhone. A user could switch devices, and the browser would continue on the alternative device where he or she left off.

When connected to the same local ad hoc wireless network, Handoff also allows a user to make calls from a Mac or an iPad. This of course requires more than just some nifty shuffling of files and work profiles in iCloud storage; it also requires inter-device continuity, using both Bluetooth 4 and Wi-Fi direct connections. This provides communication, data, and workflow between devices. From a security standpoint, however, this could lead to data being handed off to unmanaged devices or even into unauthorized apps.

With Microsoft and Google pursuing their own versions of this technology, Handoff could fundamentally change the way people use devices in the future. What is more, developers can add Handoff capability to their applications with the iOS 8 app extensions. This would enable apps to communicate with each other, thereby relaxing the sandbox concept. It is feasible that data could be passed through applications via Handoff, allowing, for example, data and information from corporate apps to be used and communicated to social media apps.

BYOD and Security

The emergence of consumer smartphones such as the iPhone brought about a shift in corporate strategy with regard to employees’ personal devices. It soon became clear that employees would much prefer to access their business e-mail accounts from their own smartphones.

This initially wasn’t a big problem for IT departments, as applicable secure technologies already existed, such as Outlook Web Access and Exchange Active Sync (EAS). Soon, however, gaining e-mail access wasn’t enough. Workers found that receiving an e-mail late in the evening requesting urgent information was pretty stressful if they couldn’t access their business files and applications. The obvious solution was to provide virtual private networks (VPNs) and Web-based applications, either in-house or as Software as a Service (SaaS), and allow employees to use their own devices to connect remotely. Eventually, there was talk of increased productivity and better work/life balance and the like. Before long, employees wanted to use their personal devices within the network boundaries. Soon, personal laptops, tablets, and smartphones began invading the workplace. For IT, this became a major challenge. The tide was irreversible, and solutions to the ensuing major security dilemmas were required.

The solution, as far as security was concerned, was to implement some measure of control and management on devices companies did not own. To do that, however, they needed a BYOD policy that was acceptable to both employees and IT management. The policy was needed to help IT with the complex task of enforcing company governance policy to ensure the network’s security was not compromised and to protect company assets (data). Data leakage—a term used to describe company data leaving the tradition network boundaries—was and remains a major security concern.

BYOD exacerbates the risk of data leakage because thousands of uncontrolled mobile devices have access to or hold company data. Compounding the problem, there soon followed a variant of BYOD: bring your own applications (BYOA). This added into the already-confusing equation nonstandard and perhaps unlicensed software as well as personal subscriptions to Google Apps and SaaS applications. A second variant of BYOA soon followed. Suddenly, employees were uploading data to iCloud, Google Drive, and Dropbox. The prospect of controlling data leakage seemed bleak.

From the perspective of IT, Windows laptops were not a problem. There had been ways to lock down and secure the Windows platform for years. The problem was with the new technologies—the smartphones and tablets that were now prevalent in the office. Fortunately, the main vendors of the most popular devices, Apple and Google, were already addressing some issues by introducing security and management features into their operating systems. These features would enable IT to set a policy template that could restrict undesirable and unsecure features and configure on the devices a uniform security policy complying with the company’s IT governance.

The Apple iPhone had by far the largest presence in the corporate workplace. It was the ideal BYOD client, because there was just one OS and only one or two models of each version of the device. In addition, Apple iOS was a closed system. If the device remained secure (that is, it wasn’t jailbroken), then many of the potential threats could be mitigated by the device’s own operating system and anti-malware. Consequently, creating security policy was straightforward. Apple iPhones and iPads had strong security and management feature sets built in to the OS. IT could devise and configure standard, uniform, and granular security policies on the iOS devices. Perhaps Apple’s natural fit with BYOD was what made it so successful in the corporate market. It soon ousted BlackBerry as the business device of choice.

Microsoft, on the other hand—the undisputed market-share leader when it comes to corporate desktop PCs and laptops—found itself being brushed aside by the iPhone and iPad and lagging behind. Windows Phone devices simply were not competitive. To address this, Microsoft concluded an exclusive deal with Nokia to use the new Windows Phone 7 operating system on its range of handsets. Unfortunately, Windows Phone 7 was introduced with no security or management features, making the configuration of a security policy for BYOD a nonstarter. It wasn’t until Windows Phone 8.1 was released in 2014 that Windows finally addressed those vital business requirements in its OS.

Android OS phones were and still are a BYOD nightmare. They are quite the reverse of Apple. The OS, which is severely fragmented, is hosted on hundreds of diverse devices from a multitude of manufacturers. Unfortunately for IT departments, however, Android devices have proven very popular with consumers, and have become a major presence in the BYOD workplace. Creating security and management policies that were standard and uniform across the Android platform was complex, despite Android having the largest security and management feature set of any of the other operating systems. This was purely due to the diversity and range of features and applications on the devices—a side effect of Android being open system and using open source code.

Clearly, if IT departments were to successfully manage BYOD, there had to be a system and policy in place that could provide, manage, and remotely deploy security policies to each device. The system would need to be able to identify and authenticate the device and check its configuration for compliance with company policy before allowing it to enter the network. The system that IT uses to provide, configure, and manage mobile devices in the workplace is mobile device management (MDM). Whereas MDM is device oriented, mobile application management (MAM) is used to manage application software on mobile devices. MDM and MAM are considered subsets of enterprise mobility management (EMM).

Security Using Enterprise Mobility Management

Enterprise mobility management (EMM) is a framework that consists of sets of people, processes, and technologies required to manage mobile IT within the enterprise. Mobile IT has come at a considerable cost, as significant security risks were introduced with the acceptance of BYOD. To combat these threats, it became necessary to find a turnkey solution that could help IT departments secure and manage a broad range of operating systems and devices. EMM has a wide scope that includes disciplines such as security, application management, and financial management.

With regard to security, system administrators’ lack of access to devices, combined with the problems of OS and device diversity, make configuring and installing applications on BYOD devices problematic. EMM solutions typically deploy middleware MDM to automate the management of a wide range of mobile devices. With the introduction of BYOD, there is a need to automate the processes involved with securing and managing mobile devices. The large numbers of diverse devices mean that a physical, hands-on approach would be feasible only in small companies. For larger companies, an automated, over-the-air provisioning, deployment, and configuration method is required.

Mobile Device Management

Mobile device management (MDM) is typically built on a client-server model whereby the MDM server controls and manages the client agent that is installed on the mobile device. MDM software can automatically detect a device on the network and can send and collect information, send updates, and configure the device over the air. MDM also allows for remote locking and remote wiping of company data from a lost or stolen device. Furthermore, updates can be sent to one or a group of devices—all iOS 8, all Android 4.4, or all Windows Phone 8.1—simultaneously. This greatly reduces the burden of administration and management of large numbers of company-owned or BYOD devices. In addition, some MDM systems have a user Web portal, which hosts device-specific apps, drivers, and updates. Employees can access this portal on a self-serve basis. On the administration side, reports can be run on just about any device’s activity. These reports include call logs, messages sent or received, apps installed or removed, configuration changes, anti-malware and antivirus versions, and last run date, all run from the central MDM server Web console.

Of all these features, the most useful is automatically configuring a registered device with a security template over the air as it attempts to join the network, by placing the device initially into a secure quarantine zone. The MDM software then interrogates the mobile device agent to retrieve security and management settings from the phone. Finally, it compares the settings to the device’s security template. The MDM can then automatically download to the device the latest versions of the security and management feature template, switching certain features on or off. (This is entirely dependent on the company policy.) Subsequently, all registered mobile phones and tablets can be kept up to date with the latest security policy automatically.

MDM servers can be hosted on site or in the cloud and delivered as a SaaS. Most MDM systems should be able to handle the tasks outlined in Table 12-1.

As can be seen from the list of MDM functions, there are some general application and software management features. However, in enterprise ecosystems, software and application management is normally handled by the MAM system.

Mobile Application Management

The main difference between mobile device management (MDM) and mobile application management (MAM) is that MDM handles the device activation, enrollment, and provisioning, whereas MAM assists in delivering software. MAM provides a distribution platform for apps with application lifestyle management and also handles software licensing, configuration, and usage tracking.

In a real-world situation MAM and MDM work together to provide parts of the overall EMM solution. The MDM system authenticates the user and inventories the device before handing control over to the MAM system to continue the process. MAM may then try to verify the presence of mandatory applications and any optional apps that are installed on the device. It might then push a catalog or individual apps to the device in accordance with the user or group profile. It also records results for software maintenance, audits, and compliance reports.

MAM has another very important role when dealing with Apple iOS or Windows Phone devices. Both of these are closed systems that place major emphasis on application provenance. As such, both of these operating systems are configured to allow only digitally signed applications to be downloaded and installed on the devices. This is a major problem if the enterprise has its own in-house developed applications that it needs to run on iPhones, iPads, or Windows Phone 8 systems. The solution is to use the vendor’s enterprise developer certificate to sign the applications. But they still need to be placed into an in-house enterprise distribution platform from which the devices can register and download the required applications. MAM provides that enterprise distribution platform and can manage the entire lifecycle of the application from release to retirement. It follows, then, that MAM is a very important part of the EMM solution.

CHAPTER 12 ASSESSMENT

1. Android permissions are the key to ensuring that one application cannot access other applications or application resources.

A. True

B. False

2. In what way does Android take advantage of Linux’s multi-user environment?

A. By growing its social media applications

B. By sharing resources between applications

C. By adapting the multi-user–based protection of isolating Android applications

D. By developing open source code

3. Which of the following best describes application provenance?

A. It helps ensure that users can trust the authenticity and integrity of the applications in the App Store.

B. It prevents applications from accessing common resources.

C. It guarantees that applications are safe and are free from malware.

D. All of the above.

4. In what way does Apple’s sandbox method differ from Android’s?

A. Apple’s App Store is more secure.

B. Apple requires the owner’s permission before granting access to an application or system feature.

C. Apple allows applications free access to system resources and features.

D. There is no difference.

5. Most security issues with Apple iOS are the result of jailbreaking, which circumvents Apple’s ability to secure applications.

A. True

B. False

6. Windows Secure Boot and application integrity ensure the authenticity and integrity of apps, making it very difficult for cybercriminals to target Windows Phone devices with effective malware.

A. True

B. False

7. In what way is the Windows Phone 8 policy control different from Android’s?

A. Android’s Google Play allows for better policy control.

B. The Windows Phone 8 policy control can be enforced on any Windows Phone device, whereas Android is fragmented across many devices.

C. Android security policy and control can be enforced on any Android mobile device, whereas Windows is fragmented across many devices.

D. There is no difference.

8. Although the Apple Handoff feature can increase productivity, it may also do which of the following?

A. It could potentially introduce malware.

B. It could undermine the benefits of application provenance.

C. It could undermine the benefits of sandboxing.

D. It could change permissions control.

9. What is the main difference between MDM and MAM?

A. MDM is used on Apple phones and MAM is used on Android phones.

B. MDM handles the device activation, enrollment, and provisioning, whereas MAM assists in the delivery of software.

C. MAM handles the device activation, enrollment, and provisioning, whereas MDM assists in the delivery of software.

D. MDM can perform integrity checks on applications.

10. MAM plays an important role in providing application provenance for custom enterprise apps on Apple iOS or Windows Phone devices.

A. True

B. False