Custom compliance policies

Ivanti EPMM provides security policies for 10 static definitions to mark a device as non-compliant. These policies have limited customization options, but are a quick and easy way to begin to set up compliance policy rules. The Compliance Policies feature allows administrators to define their own criteria for marking devices non-compliant. They can combine dozens of device and user fields to create non-compliant matching criteria.

Compliance policy rules use the Advanced Search filter criteria to define non-compliant devices. Each compliance policy rule has a filter criteria and an associated compliance action object. Access compliance policies by selecting Policies & Configs > Compliance Policies from the Admin Portal.

Ivanti EPMM uses custom device and user attributes to set up compliance policy rule conditions. These settings, listed under Devices & Users > Devices > Advanced Search > User Fields > LDAP > User Account Control in the Admin Portal, are:

  • Account Disabled
  • Locked Out
  • Password Expired

Compliance policies are enforced by Ivanti EPMM during device check-in.

The work flow to set up and use compliance policies is:

Assigning compliance roles

The following describes how to assign compliance roles.

Procedure 

  1. Log into the Admin Portal.
  2. Go to Admin > Admins.
  3. Select a user then select Actions > Edit Roles.
  4. Select an Admin Space.
  5. Scroll down the window to the Compliance Policy Management section.

    Compliance Policy Management section of the Admin Roles dialog box.

  1. Select one or more of the roles:
    • View compliance policy: Allows the selected user to view rules, groups, lists, and configuration.
    • Modify compliance policy: Allows the selected user to create, edit, and delete rules and groups.
    • Apply and remove compliance policy labels: Allows the selected user to add or remove groups from labels.
  2. Scroll to the Settings and Services Management section.
  3. Select View settings and services.
  4. Select Save.

Managing compliance policy rules

Compliance policy rules are the building blocks in compliance policy groups used to manage device compliance. Administrators create compliance policy groups, add compliance policy rules to the groups, apply the groups to labels pushed to devices. Administrators can create a group with no rules or add compliance policy rules while creating the compliance policy group, if rules have already been created. They can also modify the group, including the name, description, and selected rules. This section describes:

Creating compliance policy rules

A single rule can be in multiple compliance policy groups.

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies.
  3. Select Compliance Policy Rule tab and then select Add+.
  4. Add a unique name in the Rule Name field.
  5. Select the Status to Enabled or Disable.
  6. Enter a description of the rule if desired.
  7. Build a Condition using Advance Search to define non-compliance. For a list of definitions / values of the items to search on, see Advanced searching .

    It is recommended to have one Condition set to include when [email protected] last checked in within the last 30 days. See the TIP below.

  8. In the Compliance Actions field, select from the drop-down to use on devices matching the condition.
  9. (Optional) In the Message field, enter text for alerts generated by violations of the policy rule.
    When configuring the message accompanying the compliance action, custom attributes (see Adding custom attributes to users and/or devices) and substitution variables can be inserted into the text. To do this, copy the appropriate variable (see the The following table lists the substitution variables for compliance policy rules. table) located to the right of the Message field and paste it into the text box. Before sending the message to the device, Ivanti EPMM will replace the substitution variable to the actual value of the custom attribute for that device. For example, $FIRST_NAME$ would insert the first name of the target user into the message.
  10. If you don't want the search results to include retired devices, select the Exclude retired devices from search results check box.
  11. Select Save.

TIP - We recommend that you create a Compliance Policy rule with one condition set to include when [email protected] last checked in with Ivanti Endpoint Manager Mobile. This is helpful if you need assurance that [email protected] is running on devices (for example, for use in Mobile Threat Defense).

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies.
  3. Select Compliance Policy Rule tab and then select Add+.
  4. Enter ClientLastCheckIn in the Rule Name field.
  5. Enter Condition > All.
  6. Go to Field and type in "Client Last Check-In" or select Common Fields > Client Last Check-In.

    The regular expression is listed below; green check mark indicates regular expression is accepted.

  7. Select within the last in the Value field; enter 30 days in the remaining two fields.
  8. Keep the default setting of Exclude retired devices from search results.

  9. In the Compliance Actions field, select Send Alert from the drop-down.
  10. Select Save.

Substitution variables for compliance policy rules

The following table lists the substitution variables for compliance policy rules.

Category

Substitution variable

Compliance policy rule customized message

The substitution variables are available for use in compliance policy rules for all devices. To use in a compliance action message, copy/paste the variable into the Message field.

  • $MANAGED_APPLE_ID$
  • $CN$
  • $CONFIG_UUID$
  • $DEVICE_CLIENT_ID$
  • $DEVICE_ID$
  • $DEVICE_IMEI$
  • $DEVICE_IMSI$
  • $DEVICE_MAC$
  • $DEVICE_PIVD_ACTIVATION_LINK$
  • $DEVICE_SN$
  • $DEVICE_UDID$
  • $DEVICE_UUID$
  • $DEVICE_UUID_NO_DASHES$
  • $DISPLAY_NAME$
  • $EMAIL$
  • $EMAIL_DOMAIN$
  • $EMAIL_LOCAL$
  • $FIRST_NAME$
  • $GOOGLE_AUTOGEN_PASSWORD$
  • $ICCID$
  • $LAST_NAME$

    For Shared iPad devices and User Enrolled devices only.

  • $MI_APPSTORE_URL$
  • $MODEL$
  • $NULL$
  • $OU$
  • $PASSWORD$
  • $PHONE_NUMBER$
  • $RANDOM_16$
  • $RANDOM_32$
  • $RANDOM_64$
  • $REALM$
  • $SAM_ACCOUNT_NAME$
  • $TIMESTAMP_MS$
  • $USERID$
  • $USER_CUSTOM1$
  • $USER_CUSTOM2$
  • $USER_CUSTOM3$
  • $USER_CUSTOM4$
  • $USER_DN$
  • $USER_LOCALE$
  • $USER_UPN$

Viewing and modifying compliance policy rules

You can view or modify a compliance policy rule. Viewing a rule requires the View role and modifying a rule requires the Modify role.

You can modify a rule without removing it from an assigned group. For instance, you can change its status from Enabled to Disabled to troubleshoot it. When you modify a rule, the change is applied to all the groups that use the rule.

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies > Compliance Policy Rule.
  3. Select the name of the rule you want to modify and select Edit.
  4. Modify details, as necessary, including disabling the rule.
  5. Select Save.

Deleting compliance policy rules

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies > Compliance Policy Rule.
  3. Select the name of one or more rules to delete.
  4. Select Actions > Delete.

Searching for compliance policy rules

Procedure

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies > Compliance Policy Rule.
  3. Enter a name in the search field.
  4. Use one of the following filters:
    • All
    • Enabled
    • Disabled
  5. Select Search.

Managing compliance policy groups

Compliance policy groups are applied to devices to manage device compliance. Administrators create compliance policy groups, add compliance policy rules to the groups, apply the group's rules to devices matching the label criteria.

Administrators can create a group with no rules or add compliance policy rules while creating the compliance policy group, if rules have already been created. They can also modify the group, including the name, description, and selected rules. This section describes:

Creating compliance policy groups

You can create a group without adding rules, which can be added later. One rule can be member of multiple groups.The following provides the steps to add one or more compliance policy rules to a compliance policy group.

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies.
  3. Select Compliance Policy Group tab.
  4. Select Add+. The Add Compliance Policy Group page displays.
  5. Enter a unique name in the Group Name field.
  6. Select Enabled in the Status field.
  7. Move one or more rules from Available Rules to the Selected Rules list.
  8. Select Save.

Modifying compliance policy groups

The following provides the steps to modify compliance policy groups.

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies > Compliance Policy Group.
  3. Select the name of the group you want to modify.
  4. Modify details, as necessary, including the name, description, or to enable or disable the group.
  5. Select Save in the Details section.
  6. Select Edit in the Rules section.
  7. Modify rules, as necessary, by adding or removing rules.
  8. Select Save in the Rules section.

Adding compliance policy rules to a group

One rule can be a member of multiple groups. This procedure requires that you have already created one or more rule. See Creating compliance policy rules for details.

Procedure

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies > Compliance Policy Group.
  3. Double-select the name of the group to which you want to add one or more rules.
  4. Go to the Rules section and select Edit.
  5. Move one or more rules from the Available Rules list to the Selected Rules list.
  6. Select Save in the Rules section.

Applying compliance policy groups to labels

Once a group (and its underlying rules) is assigned to devices, status of the devices are evaluated based on the conditions in the rules for compliance. Compliance Policy rules are evaluated against each device in the following ways:

  • During device check-in
  • Periodically, during the compliance policy check interval. This is set at Policies & Configs > Compliance Actions > Preferences.
  • When a manual Check Compliance is initiated by the administrator. This can be set at Policies & Configs > Compliance Actions > Check Compliance or on the Devices page under Actions.

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies > Compliance Policy Group.
  3. Select the name of the compliance policy group you want to apply to label.
  4. Select Actions > Apply to Labels.
  5. Select one or more of the labels.
  6. Select Apply.

Removing compliance policy groups from labels

Once a group (and its underlying rules) is assigned to devices, status of the devices are evaluated based on the conditions in the rules for compliance. The following describes the steps to apply a compliance policy groups to one or more labels.

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies > Compliance Policy Group.
  3. Select the name of the compliance policy group you want to remove from a label.
  4. Select Actions > Remove from Labels.
  5. De-select one or more of the labels.
  6. Select Apply.
    After the next device check in, these changes will apply.

Deleting compliance policy groups

The following provides the steps to delete one or more compliance policy groups.

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies > Compliance Policy Group.
  3. Select the name of one or more groups to delete.
  4. Select Actions > Delete.

Searching for compliance policy groups

The following provides the steps to search for compliance policy group.

Procedure 

  1. Go to the Admin Portal.
  2. Select Policies & Configs > Compliance Policies > Compliance Policy Group.
  3. Enter a name in the search field.
  4. Use one of the following filters:
    • All
    • Enabled
    • Disabled
  5. Select Search.

Device search fields for compliance rules

This section includes the compliance action objects the compliance policy rules use for device search fields. In addition to the fields listed in the below table, any Custom Device Attributes or Custom User Attributes that were added in Settings > System Settings > Users & Devices > Custom Attributes will also be available for searching.

The following table lists the available objects, including:

  • Common fields
  • Custom fields
  • Android devices
  • iOS devices
  • Windows devices
  • User fields (including LDAP fields)
Table 21.   Device search fields for compliance rules

Category

Compliance policy objects

Common

The following search fields are available for use in compliance rules for all devices:
cellular_technology, client_name, client_build_date, client_version, creation_date, current_country_code, current_country_name, country_name, current_operator_name, carrier_short_name, current_phone_number, current_phone_number, data_protection_enabled, data_protection_reasons, device_admin_enabled, device_encrypted, device_is_compromised, eas_last_sync_time, ethernet_mac, home_country_code, home_country_name, home_operatory_name, home_phone_number, imei, imsi, language, last_connected _at, locale, location_last_captured_at, manufacturer, mdm_managed, mdm_tos_accepted, mdm_tos_accepted_date, model, model_name, os_version, owner, pending_device_passcode, pending_device_passcode_expiration_time, platform_name, platform, registration_date, registration_imsi, retired, roaming, security_state, status, uuid, wifi_mac_address

Android

The following search fields are available for use in compliance rules for all Android devices:
admin_activated, attestation, afw_capable, brand, Client_version_code, device_roaming_flag, knox_version, manufacturer_os_version, mdm_enabled, multi-mdm, os_build_number, os_update_status, registration_status, samsung_dm, secure_apps_encryption_enabled, secure_apps_encryption_mode, security_detail, security_patch, usb_debugging, dpm_encryption_status

iOS

The following search fields are available for use in compliance rules for all iOS devices:
BluetoothMAC, BuildVersion, CarrierSettingsVersion, Current MCC, Current MNC, DataRoamingEnabled, data_protection, forceEncryptedBackup, iCloud Backup Is Enabled, iOSBackgroundStatus, iPhone PRODUCT, iPhone VERSION, IsDeviceLocatorServiceEnabled, IsDEPEnrolledDevice, IsDoNotDisturbInEffect, IsMDMLostModeEnabled, IsMDMServiceEnrolledDevice, iTunesStoreAccountIsActive, ProductName, PasscodePresent, PasscodeIsCompliantWithProfiles, PasscodeIsCompliant, Personal Hotspot Enabled, SerialNumber, Supervised, SIM MCC, SIM MNC, Subscriber Carrier Network, Voice Roaming Enabled, osUpdateStatus,

Windows

The following search fields are available for use in compliance rules for all Windows devices:
dm_client_version, wp_firmware_version, wp_hardware_version, wp_os_edition, health_data_issued, health_data_aik_present, health_data_dep_policy, health_data_bit_locker_status, health_data_boot_manager_rev_list_version, health_data_code_integrity_rev_list_version, health_data_secure_boot_enabled, health_data_boot_debugging_enabled, health_data_os_kernel_debugging_enabled, health_data_code_integrity_enabled, health_data_test_signing_enabled, health_data_safe_mode, health_data_win_pe, health_data_elam_driver_loaded, health_data_vsm_enabled, health_data_pcr0, health_data_sbcp_hash,

User

The following search fields are available for use in compliance rules user-related fields, including LDAP:
email_address, user_id, attr_dn, dn, name, locale, principal, upn, account-disabled, locked_out, password_expired, custom1, custom2, custom3, custom4, <dynamically created custom user-attribute field name #1>, <dynamically created custom user-attribute field name #2>, <dynamically created custom user-attribute field name #3>, <dynamically created custom user-attribute field name #4>, <dynamically created user-attribute field names>

Independent, customized messages and email subject for each compliance action tier

In previous releases, only one customized message could be sent for all Compliance Action tiers supported in Compliance Policies > Compliance Policy Rule. Starting in this release, administrators have the ability to create and send independent, customized messages and email subject lines for each of the now 20 possible Compliance Action tiers.

Compliance actions are categorized as:

  • V1, which are compliance actions that existed in Ivanti EPMM before Version 11.8.0.0.

  • V2, which are compliance actions that are created starting in Ivanti EPMM 11.8.0.0.

The following table compares compliance actions between V1 (pre-version 11.8.0.0) and V2 (Version 11.8.0.0+):

V1 V2

Uses even center for alert-related settings.

Actions cannot use the event center configuration. Instead, all the settings related to alerts, message languages, and so on, are available in the action page in the Settings tab.

Compliance action messages are configured at rule level. Only one message can be configured for all tiers in an action

Compliance action messages can be configured in each tier.

Uses only single alert messages across all tiers in the action.

Administrators can configure alert messages and subjects in multiple languages selected in the action settings. The system default language is mandatory and cannot be ignored or removed. Once an administrator selects languages, they must enter the subject and message for all the selected languages.

When the system dispatches messages to the devices, it picks the language specified in the device locale. If the device-specific locale is not configured in the action page, the system default language (for example, English) is used. For example, if an administrator configures messages in French and English, but the device locale (German), has not been configured, the subject and messages use the system default language (English) in alerts.

Uses event center.

Administrators can configure different messages for each tier in multiple languages and configure the alert severity levels and alert frequency settings for each tier in an action. Alert recipients and message languages can be configured at an action level in the compliance action page > Settings tab.

Existing behavior is unchanged.

For V2 actions, the maximum length of the message = 800 chars, including substitution variables. The maximum length of the subject = 150 chars, including substitution variables.

After upgrading to Ivanti EPMM 11.8.0.0, existing V1 actions can be used. New V2 actions can also be used. New actions can only be created as V2 actions.

Administrators can upgrade/migrate V1 actions to V2 actions. When they edit V1 actions, they can apply V2 action features to V1 actions and upgrade/migrate the V1 action to a V2 action using the Upgrade to New Compliance Action checkbox in the Edit Compliance Action page. This upgrade is non-reversible, that is, the upgraded/migrated V1 cannot be reverted if it has been successfully migrated to V2.

After upgrading/migrating to Ivanti EPMM 11.8.0.0, new actions can only be created as V2 actions.

Supports templates in the event center.

Templates

Administrators can insert the following variables (that are exposed in the Insert Variable section) in the subject and message content:

  • $SEVERITY$ - Localized, device’s locale used.

  • $USER_NAME$

Existing behavior is unchanged.

Alert frequency time has granularity to hours and days. For example, administrators can send up to 5 alerts in 5 hours, or 10 alerts in 2 days. Two days duration = 24 * 2 = 48 hours.

Delay of the next tier should be greater than or equal to the Sendupto value of the current tier in the V2 action.

Supports up to 4 tiers.

Supports up to 20 tiers.

Existing behavior is unchanged.

When multiple rules are associated with a single action, upgrading to Ivanti EPMM 11.8.0.0 creates new, distinct action.

For example, in an existing compliance action setup:

  • Rule1 with message1 causes Action1.

  • Rule2 with message2 causes Action1.

  • After upgrading to 11.8, for Rule2, new Rule1-Action1 and Rule2-Action1 exist as distinct actions. This is because you now edit messages in the action page, not the rule page, and Rule1 and Rule2 use the same action, but different messages.

  • Message2 is associated with all the tiers of Action2 as the system default language message. This action usually occurs automatically during an upgrade. However, administrators can customize message2 on the Edit Compliance action page.

 

After upgrading to Ivanti EPMM 11.8.0.0+, a default system-generated event of type Compliance Rule Violation Event is generated in the Event Settings page. This event cannot be edited or deleted.

 

When a compliance policy rule violation occurs, the system uses tier-specific alert preferences. Security policies continue to use the alert preferences from the event center.