Streamlining Device Compliance and Tags with Workspace ONE UEM

Device compliance is a key component of Workspace ONE UEM, it enables IT administrators to enforce compliance policies on managed devices based on a set of parameters related to device attributes and applications. When devices are identified as non-compliant, a set of actions can be executed based on the compliance policy configuration. Additionally, the device can be marked as non-compliant, which will block its access to internal resources through Workspace ONE Tunnel and Single Sign-On to applications through Workspace ONE. When the device is compliant again, its access to previously blocked resources is restored.

Device compliance rules are based on a list of pre-defined parameters, such as application list, data roaming, antivirus status, device last seen, and so on. A full list of parameters is available in Compliance Policies Rules and Actions. During customer conversations, a frequent question that arises is “Can I set a device out of compliance on my own, or can I customize the list parameters in UEM”, the answer to both questions now is YES. Workspace ONE UEM 2306 brought the ability to leverage Device Tags as part of compliance policy, a powerful feature that unlocks endless possibilities to determine when a device is non-compliant, including the ability to automate this process with Freestyle automation.

Defining Compliance Rules based on Tags

With the new Device Tags rule, administrators have greater control over the conditions to determine if the device is not compliant. It can be based on all, any, or none of the tags defined in the rule. Other attributes can be combined to the rule in the same way you have been using compliance up to today, no changes there. The new Device Tags rule is supported on the following platforms: iOS, Android, macOS, Windows, and Rugged.

Actions continue to be executed in the same way, based on the defined rules with the ability to evaluate device tags. For example, you take an action to Block/Remove a specific managed app or all of them and mark the device as not compliant when the device is tagged. Once the device is non-compliant and depending on escalation actions, the system will block the device from accessing resources and might block admins from deploying additional resources to the device. Deselect this option when you do not want to restrict device access to resources immediately.

The compliance policy will be assigned to a group of devices based on Smart Groups. As the policy is activated and devices start reporting sampling to Workspace ONE UEM, the compliance engine verifies the sample against the defined rule and takes action based on what was defined.

How to use Tags in real scenarios to trigger devices out of compliance?

There are several approaches to take a device out of compliance when leveraging tags, such as tagging devices manually, via APIs, automation, and others. For this article, let’s focus on:

Manually tagging the device in Workspace ONE UEM console
Leveraging Freestyle workflows to automate device tagging on UEM based on endless attributes available through the workflows

Let’s dig into this.

Manually tagging devices in Workspace ONE UEM

IT admins can simply tag a device(s) through the Workspace ONE UEM console in situations where a device needs to be isolated immediately and marked non-compliant, due to security reasons beyond the scope of device posture.

Figure 1: Administrators can easily identify non-compliant devices using the UEM console.

When the device sample data is received by Workspace ONE UEM, it gets evaluated against the compliance rules and marked as non-compliant if found to be in violation.

Figure 2: Administrators can use the device details view to identify specific compliance violations.

Removing the tag using the Workspace ONE UEM console will initiate the same process and bring the device into compliance, restoring access to the corporate resources.

Automating Device Tags with Freestyle Workflows

Most likely you want the system working for you, monitoring anomalies across all your devices and automatically tagging them; that is where automation through Freestyle workflows will help.

Freestyle workflows can be automated to execute based on attribute changes from several data sources, such as Workspace ONE UEM (device, apps, sensors, risk score, and so on.) Mobile Threat Defense, Trust Network partners, and others that are integrated into the platform.

The extensive list of data sources brings flexibility to the administrator to evaluate the list of respective attributes that go beyond the Workspace ONE platform.

Figure 3: Source of data available to define the workflow conditions.

The workflow conditions (trigger rules) enable the administrator to define parameters that go beyond the UEM static list. In Freestyle, you have the flexibility to leverage a large list of attributes to ensure the compliance of the devices. As an example, you can look for specific configurations that might not be available out-of-the-box but can be obtained by Sensors. The following example shows a condition based on BitLocker parameters to determine if the device is complying or not. The system can return if the device is encrypted. However, as the administrator, I want to ensure the encryption configuration of the system is done properly and in compliance with company security policies, otherwise the device will be denied access to corporate resources.

Figure 4: Workflow conditions evaluated by the automation engine.

Finally, an action must be executed when the device doesn’t meet the rule conditions. That is where we add the “Add Tag to Device” action to the workflow to tag the device in Workspace ONE UEM. From this point, when UEM receives a new device sample, it will identify the device tag and perform the actions defined in the device compliance policy.

Figure 5: Workflow action leveraging UEM Rest APIs to tag the device in Workspace ONE UEM.

Continuous monitoring of the device is important here, later the administrator can properly set the BitLocker configuration to ensure the device is encrypted correctly. This will require a second workflow that removes the device Tag bringing the device to compliance. In this case, the second workflow requires an updated rule representing the correct BitLocker configuration, and the “Remove Tag from Device” action, which will bring the device to compliance when Workspace ONE UEM evaluates the next sampling.

Figure 6: Workflow condition that defines a device in compliance.

Figure 7: Workflow action based on UEM action Remove Tag to Device.

Summary

The new Device Tags rule added to Device Compliance streamlines and extends the capability to define when devices are out of compliance. It’s no longer limited to a pre-defined list, instead, it extends through all data source attributes available in Workspace ONE Intelligence, integrating Freestyle workflows to enable the orchestration across the platform without the need to develop code, custom scripts, or perform complex integrations that require advanced skill sets.

To learn more about device compliance and how it integrates across Workspace ONE to increase security, check out the following articles: