Application Delivery Management
Application Modernization & Connectivity
CyberRes
IT Operations Management
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.
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:
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:
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.
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
There are a few pre-requisites you should meet:
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.
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.
Once you have your profile ready, it is a simple process to create an iOS Profile 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.
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.
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.