Some time back, a discussion with one of my colleagues got me thinking on the importance of blacklisting or whitelisting of applications on devices and its current relevance.

To provide some background, some years back, the MDM capabilities offered by Operating Systems were not that mature and in order to protect users from malicious applications residing on devices and ensure security of their corporate data, most MDM vendors provided an ability to whitelist / blacklist applications on the user's personal devices (Belonging to end users and containing the user's personal data). In the initial days of MDM, it was actually possible to restrict applications being installed, even on personal devices, but with the maturity of operating systems this ability soon went away. At this point, MDM vendors provided blacklisting/whitelisting ability by detecting personal applications on devices and then restricting or disabling the access to corporate data.

But in the current context where native MDM capabilities provided by Operating Systems have matured, user privacy is key, is this still relevant? To answer this, it is best to first understand different ways a mobile device can be managed.

Different Management Modes

Both Apple & Google, through their operating systems, now offer basically 2 types of device management.

Containerization / MAM Solution  - In this management paradigm, IT admins create and control a container (generally virtual) on the device. IT admins have full control over everything inside the container, but little or no control on everything outside. This generally maps to BYOD scenario where users enroll their personal devices into MDM and expect admins to control only limited aspect of their devices. Within the container, all applications are provisioned by the admin only, while the user is free to install/run any application outside the container.

However, in container based management, it is now very difficult (if not impossible) to detect what is happening outside user space. To take an example, with Android Enterprise Work Profile, it is not possible to detect what applications are running on the personal side. With iOS devices, it is currently possible, but with the current push for user privacy, this may not be possible for long. In this scenario, the methodology of detecting a user's malicious applications and then restricting devices till the applications are removed, just falls flat. As an IT admin, if you are looking to restrict or limit the applications on a device, container based management is unlikely to work for you.

Device Management - In this management paradigm, IT admins own the device. In this type of management, devices are factory reset (if not new) and then enrolled directly into MDM solution. At this point, IT admins have complete control over the device including what applications can be there and what not. In this mode of management, there exists 2 main scenarios:

• • IT admins choose to provision only certain applications to devices and disable the application store, so no other applications can be installed/downloaded.

• • IT admins can choose to lock down a device to only one application (Single Application Mode)

However, if provisioned devices are also used for some personal work, both the above approaches may not work. In such situations, there do exist use cases for use of blacklisting or whitelisting of applications. So, let’s examine what some of these use cases can be:

When to have a blacklist of applications:

• •  When we think of blacklisting, the most obvious case which pops up is that you don't want certain applications say like (Facebook / Instagram) on managed devices. However, if it is possible to download any set of applications on the device, the list of blacklisted applications can increase at an alarming rate. Thus, in most scenarios, application blacklisting can only work best when App Store is unavailable to the end user, resulting in only approved applications being available on device. However, if all available applications on the device are approved, it means that there is no need to blacklist applications in the first place.

• • There is the not so typical use case, where application blacklist can actually work. Consider a scenario, where only approved applications are available on the device (App Store is unavailable to end user), however, for some reason (say during a test) you want to remove some applications for certain occasions. Here blacklisting applications for a certain time/occasion can actually help.

When to have a whitelist of applications?

• • By definition, an application whitelist means that only a selected set of applications are allowed on the device. In scenarios where App Store is unavailable to the end user, the list of provisioned applications essentially constitutes an application whitelist and there are fewer reasons to enforce an application whitelist.

• • However, in scenarios where App store is available to the end user, application whitelist can really help. This can help you fulfill use cases where you want a fixed set of applications available on the device at one time, and another set of applications available at another time.

• • Yet another use case can be fulfilled using application whitelist where at a certain time you may want a specific set of applications and the rest of the time you may not care at all. To take an example, assume in a school, students are using devices issued by the school and are free to use their devices however they wish after school hours. However, during school hours you may want them to have only a specific set of applications available on the device.

Behaviour of application whitelist/blacklist on iOS Devices 

On iOS devices, when you blacklist an application and if it is already installed, it doesn't get uninstalled, but gets hidden. Similarly, when you whitelist a set of applications, other applications installed on the device don't get uninstalled but are hidden.

This behaviour can help IT admins help solve many of above mentioned use cases, where some applications are needed at one time and others at another time. So potentially an application whitelist can be deployed only during school hours, allowing end users access to all applications outside school hours without any loss of data. Depending upon your use case, you can do the same with application blacklist. Essentially, without needing to change your overall application assignments, you can choose to hide or make some applications visible.

One thing to be noted is that on iOS devices it is possible to blacklist/whitelist every application (including system applications) apart from the following 2 system applications - Settings & Phone.

Creating Blacklist/Whitelist on iOS Devices using ZENworks 2017

With ZENworks 2017, it is possible to blacklist/ whitelist applications on a supervised iOS Device using iOS profile bundle. It is one of those under the cover features which greatly enhance what you can do on iOS devices with ZENworks. Using an iOS profile bundle you can create an application blacklist or application whitelist and deploy it on managed iOS devices just like any other bundle. Let's see how it can be done

Prerequisites:

There are a few pre-requisites you should meet:

• • You should be using ZENworks 2017 or later.

• • You can only apply blacklist/whitelist profile to a ‘Supervised’ iOS Device. You can check if the device is ‘Supervised’ or not in the Device info page of the device.

Whitelist/Blacklist Profile

Before we go ahead and create a bundle and deploy it, let’s quickly examine the profile itself. I am attaching 2 different profiles (one for blacklist and another for whitelist). These profiles have been generated using Apple Configurator and can be used with very minor changes (as explained below). Extract the zip and the included file can be opened in any text editor. The profiles have many parts, but I’ll limit myself to things you should change. There is only a section in each profile you should consider changing:

Blacklist App Profile

<key>blacklistedAppBundleIDs</key>
<array>
<string>com.google.chrome.ios</string>
</array>

Whitelist App Profile

<key>whitelistedAppBundleIDs</key>
<array>
<string>com.google.chrome.ios</string>
</array>

In the case of a Blacklist App profile, the Google Chrome application would be blacklisted and won't be available to the end user. In the case of a Whitelist App Profile, only the Google Chrome (apart from Phone & Settings) application would be available to end user. In both profiles, instead of Google Chrome, you can add bundle identifiers of your choice. Multiple bundle identifiers can be added, with one in each line.

Looking up bundle identifier

Since you would want to put in your application list, you need to find out the bundle identifiers for each application you need. With ZENworks Update 3, you can create a bundle for an application within ZENworks and go to the bundle summary page where this bundle identifier would be visible.  Alternatively, you can choose to follow the steps mentioned in this link to retrieve the bundle identifier for the application of your choice. A comprehensive list of bundle identifiers of iOS system applications is available here.

Creating an iOS Profile Bundle

Once you have your profile ready, it is a simple process to create an iOS Profile Bundle.

1. 1. In ZCC, launch the New Bundle wizard.

1. 1. Select Bundle Type as iOS Bundle, Bundle Category as iOS Profile

1. 1. On the next page, provide Bundle Details

1. 1. On the next page, upload the profile you have just edited

1. 1. Save the bundle

At this point, you can publish this bundle just like any other ZENworks bundle, and upon installation, it would blacklist / whitelist the applications as you have specified.

Using System Variables

In some scenarios, you may want a different application for a different set of devices without make changes to the profile. In such cases, instead of using multiple bundles, you can create a single bundle and use ZENworks system variables. You can use a variable name like – say ${AppName} in place of com.google.chrome.ios in the profile. Then for a set of devices you can define a variable ‘AppName’ with the appropriate bundle identifier. ZENworks would resolve the variable and substitute it with the correct application identifier before deploying the profile.

Summary

Though use cases for application whitelist/blacklist may have receded over time, there are still some very important use cases where it can prove beneficial. The iOS profile bundle in ZENworks 2017 provides a simple but powerful way to unlocking some of these use cases for iOS devices.