Zimperium Delivery and Activation on Android Enterprise with Workspace ONE UEM Product Provisioning
A use case I am involved in required remotely delivering Zimperium zIPS, a mobile threat detection and response security product, to Android Enterprise devices with Workspace ONE UEM. Zimperium is an incredible mobile security product, which I will discuss more in upcoming blog posts. The way Workspace ONE and Zimperium compliment each other is ideal for securing devices running (Android and iOS supported). First we need to deliver zIPS; and this will cover the delivery and activation of zIPS on an Android Work Managed device with Workspace ONE UEM Product Provisioning.
For zIPS to secure a device, report threats back to Zimperium's zConsole and eventually Workspace ONE Intelligence; zIPS requires activation on each device. It sounds daunting, especially because it isn't just delivering an apk file and managed configuration. If you have a fleet of 15,000 or 150,000 devices; you wouldn't want to visit each point-of-sale kiosk, in-flight entertainment system, medical device, or ATM and launch zIPS; right? For zIPS to activate; zIPS must install with the correct managed configuration, granted permissions before application runtime (to not interrupt the foreground activity, which is a secured, pinned Launcher), before finally passing an intent with Product Provisioning.
The intent launches the Android application's package name and component class name required to activate zIPS. Once activation is attempted, zIPS will only register the device record with the zConsole if it is allowed. The device is allowed if the zConsole is already aware of the devices deviceID that it obtained from Workspace ONE UEM. zConsole obtains this with a series of ad-hoc API calls or by preloading the devices in a nightly sync (which is also performed with a series of API calls). Ensuring you have Workspace ONE UEM API's publicly accessible is a requirement for this integration to work. Because Workspace ONE is already on an Android device as a device owner in our use case, zIPS doesn't have to be device owner of the device for it to add another layer of security on the device.
Think of intents as like command lines with arguments that you can explicitly send to a single thing (explicit intent), or to anything that can listen for that intent. These things that listen for intents are intent-filters in your application. I prefer explicit intents, as they are meant for a specific recipient. Adam Cozzette has a great article on intent spoofing for more about why this is a more secure choice. http://blog.palominolabs.com/2013/05/13/android-security/index.html
Workspace ONE UEM can only run (or start) activities defined with android:exported=true in the apks AndroidManifest.xml file. Google defines how intents work in the Android OS at: https://developer.android.com/guide/components/intents-filters
Knowing how intents, intent-filters and how your Android application can be managed with Workspace ONE Product Provisioning is really the key, and a really creative away to approach different use cases that were otherwise more challenging. For a comprehensive read on Product Provisioning, see VMware documentation at https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/1903/WS1_ProdProv_for_Android.pdf
The Product in Workspace ONE UEM has a manifest, which is one or many components you define. A component can be an application, profile, or Files/Actions. The file/action component has the capability of delivering commands as if they were running interactively from adb shell. The sequence of the component manifest is outlined below:
Overview:
4. Save Profile. Example screenshot from ‘Custom Settings’:
Product Manifest Step 2.
For zIPS to secure a device, report threats back to Zimperium's zConsole and eventually Workspace ONE Intelligence; zIPS requires activation on each device. It sounds daunting, especially because it isn't just delivering an apk file and managed configuration. If you have a fleet of 15,000 or 150,000 devices; you wouldn't want to visit each point-of-sale kiosk, in-flight entertainment system, medical device, or ATM and launch zIPS; right? For zIPS to activate; zIPS must install with the correct managed configuration, granted permissions before application runtime (to not interrupt the foreground activity, which is a secured, pinned Launcher), before finally passing an intent with Product Provisioning.
The intent launches the Android application's package name and component class name required to activate zIPS. Once activation is attempted, zIPS will only register the device record with the zConsole if it is allowed. The device is allowed if the zConsole is already aware of the devices deviceID that it obtained from Workspace ONE UEM. zConsole obtains this with a series of ad-hoc API calls or by preloading the devices in a nightly sync (which is also performed with a series of API calls). Ensuring you have Workspace ONE UEM API's publicly accessible is a requirement for this integration to work. Because Workspace ONE is already on an Android device as a device owner in our use case, zIPS doesn't have to be device owner of the device for it to add another layer of security on the device.
Think of intents as like command lines with arguments that you can explicitly send to a single thing (explicit intent), or to anything that can listen for that intent. These things that listen for intents are intent-filters in your application. I prefer explicit intents, as they are meant for a specific recipient. Adam Cozzette has a great article on intent spoofing for more about why this is a more secure choice. http://blog.palominolabs.com/2013/05/13/android-security/index.html
Workspace ONE UEM can only run (or start) activities defined with android:exported=true in the apks AndroidManifest.xml file. Google defines how intents work in the Android OS at: https://developer.android.com/guide/components/intents-filters
Knowing how intents, intent-filters and how your Android application can be managed with Workspace ONE Product Provisioning is really the key, and a really creative away to approach different use cases that were otherwise more challenging. For a comprehensive read on Product Provisioning, see VMware documentation at https://docs.vmware.com/en/VMware-Workspace-ONE-UEM/1903/WS1_ProdProv_for_Android.pdf
The Product in Workspace ONE UEM has a manifest, which is one or many components you define. A component can be an application, profile, or Files/Actions. The file/action component has the capability of delivering commands as if they were running interactively from adb shell. The sequence of the component manifest is outlined below:
Overview:
1. Install Profile containing zIPS application configuration (key value pairs)
2. Install zIPS application (apk)
3. Install Profile granting zIPS permissions*
4. Install Files/Actions containing first activity intent
5. Install Files/Actions containing second activity intent
2. Click ‘Add Profile’, and specify ‘Android’, followed by naming the profile appropriately
3. In ‘Custom Settings’, click ‘Configure’ and paste the XML below with correct TenantID & DefaultChannel values:
Product Manifest Step 1.
1. Navigate to Devices -> Provisioning -> Components -> Profiles2. Click ‘Add Profile’, and specify ‘Android’, followed by naming the profile appropriately
3. In ‘Custom Settings’, click ‘Configure’ and paste the XML below with correct TenantID & DefaultChannel values:
4. Save Profile. Example screenshot from ‘Custom Settings’:
Product Manifest Step 2.
1. Navigate to Devices -> Provisioning -> Components -> Applications
2. Add Application
3. Upload the APK file for Zimperium
4. Once the APK upload completes. Save the application. Example screenshot from ‘Applications’ in the ‘Components’ section of the Workspace ONE UEM console
Product Manifest Step 3.
* This step requires adding Zimperium IPS as a public application, as Permissions profiles will not let you define Permissions for internal application packages (com.zimperium.zips).
1. Navigate to Apps & Books -> Native -> Public
2. Click ‘Add Application’
3. Select ‘Platform’ drop-down and specify ‘Android’
4. Click ‘Next’ to search the application store
5. Complete the wizard to add the Zimperium IPS application as a ‘Public’ application.
6. ‘Public’ applications will show Zimperium Mobile IPS once this is complete
7. Navigate to Devices -> Provisioning -> Components -> Profiles
8. Click ‘Add Profile’, and specify ‘Android’, followed by naming the profile appropriately
9. Click ‘Permissions’ and click ‘Configure’
10. In the ‘Exceptions’ form-field, specify ZIMPERIUM Mobile IPS
11. Click ‘Configure’
12. Ensure every permission requested is set to ‘Grant’
13. Click ‘Save’
14. Ensure the profile is named appropriately in the ‘General’ tab, and click ‘Save’
6. Click ‘Add Action’
7. In ‘Actions To Perform’, specify ‘Run Intent’
8. In the ‘Command Line and Arguments to run’ form-field, specify:
9. In the TimeOut value form-field, specify -1
10. Click ‘Save’
11. Click ‘Save’ to save the Files/Actions
Product Manifest Step 5.
1. Navigate to Devices -> Provisioning -> Components -> Files/Actions
2. Click ‘Add Files/Actions’
3. Select ‘Android’
4. Name the Add Files/Action component appropriately
5. Click ‘Manifest’ (as previously performed in Product Manifest Step 4).
6. Click ‘Add Action’
7. In ‘Actions To Perform’, specify ‘Run Intent’
8. In the ‘Command Line and Arguments to run’ form-field, specify:
9. In the TimeOut value form-field, specify -1
10. Click ‘Save’
11. Click ‘Save’ to save the Files/Actions
Product Manifest Step 4.
1. Navigate to Devices -> Provisioning -> Components -> Files/Actions
2. Click ‘Add Files/Actions’
3. Select ‘Android’
4. Name the Add Files/Action component appropriately
5. Click ‘Manifest’
7. In ‘Actions To Perform’, specify ‘Run Intent’
8. In the ‘Command Line and Arguments to run’ form-field, specify:
9. In the TimeOut value form-field, specify -1
10. Click ‘Save’
11. Click ‘Save’ to save the Files/Actions
Product Manifest Step 5.
1. Navigate to Devices -> Provisioning -> Components -> Files/Actions
2. Click ‘Add Files/Actions’
3. Select ‘Android’
4. Name the Add Files/Action component appropriately
5. Click ‘Manifest’ (as previously performed in Product Manifest Step 4).
6. Click ‘Add Action’
7. In ‘Actions To Perform’, specify ‘Run Intent’
9. In the TimeOut value form-field, specify -1
10. Click ‘Save’
11. Click ‘Save’ to save the Files/Actions
Create Zimperium IPS Product
1. Navigate to Navigate to Devices -> Provisioning -> Product List View
2. Click ‘Add Product’
3. Specify ‘Android’
4. Name the Product appropriately
5. Assign the product to the Smart Group of devices you want to receive Zimperium
1. Navigate to Navigate to Devices -> Provisioning -> Product List View
2. Click ‘Add Product’
3. Specify ‘Android’
4. Name the Product appropriately
5. Assign the product to the Smart Group of devices you want to receive Zimperium
6. Click ‘Manifest'
7. Click ‘Add’ to add each of the (5) components previously created. The order of the steps is;
7. Click ‘Add’ to add each of the (5) components previously created. The order of the steps is;
1. Profile – App Config
2. Application
3. Profile – Permissions
4. Files/Actions – DormancyStartActivity
5. Files/Actions – ZipsActivity
Example:
2. Application
3. Profile – Permissions
4. Files/Actions – DormancyStartActivity
5. Files/Actions – ZipsActivity
Example:
8. Click ‘Deployment’
9. Ensure ‘Pause/Resume’ checkbox is checked
10. Ensure ‘Product Type’ is ‘Required’
11. Click ‘Activate’
12. Click ‘Save’
13. Ensure the Product List View displays the product with a green icon, indicating the product is enabled
14. Devices will begin to receive Zimperium at this time. The product will take under 1 minute to complete with broadband connectivity. Allow additional time for step 2 to complete the APK download in bandwidth constrained environments.
Note:
If the permissions profile does not have Zimperium zIPS added as an ‘Exception’, not all permissions requested by zIPS will be granted automatically.
If your device has Launcher pinned and running in the foreground, Zimperium zIPS will need to be added as a hidden application in Launcher, unless you wish for application icon to be visible in Launcher
Once zIPS is protecting your device, there is a patented z9 engine that runs in the background on the device. The device remains protected in both connected and air-gapped/offline use cases. The z9 engine operates in tandem with configurable policies with remediation actions based on the configurable responses. To see the delivery in action, take a look at a video that I used in a prior blog post.
Note:
Once zIPS is protecting your device, there is a patented z9 engine that runs in the background on the device. The device remains protected in both connected and air-gapped/offline use cases. The z9 engine operates in tandem with configurable policies with remediation actions based on the configurable responses. To see the delivery in action, take a look at a video that I used in a prior blog post.
Mahalo,
Ryan Pringnitz
Comments
Post a Comment