Creating Device Posture Profiles and Device Checks (EA)

This article discusses how to create Device Posture Profiles and Device Checks to make sure that only devices that meet the security requirements are allowed to connect to the network.

Note

Note: Process, Registry Keys, and Property List checks are Early Availability (EA) features that are only available for limited release. For more information, contact your Cato Networks representative or send an email to ea@catonetworks.com.

Overview

Device Posture Profile and Checks let you enforce compliance requirements for remote users before they are allowed to connect to the Network. You can use them in the Client Connectivity Policy and Internet and WAN firewall to define the specific device requirements.

For example, you can create a Device Check for a specific Anti-Malware vendor, product, and version. The Client checks that this software is installed on the device before connecting to the network. The Client only connects to the network if it identifies this software is installed on the device. For more information on the Client Connection flow, see Understanding the Cato Client Connection Flow.

Various Device Checks can be configured. See the Prerequisites section for a list of available Device Checks and the Working with Specific Device Checks and Features for additional information on each check.

Device Checks can be added to Device Profiles that can contain multiple checks. Device Profiles can be added to the Client Connectivity Policy to determine which devices are allowed to connect to the network.

Device Profiles can also be used in the Internet and WAN firewall to create rules that include conditional access based on the actual device of the end-user. For more about using Device Checks in a firewall policy, see Adding Device Conditions to Firewall Rules. You can monitor the number of devices that have complied with each Device Posture Profile on the Remote User Dashboard.

Device Checks in an Office

Starting from Windows Client v5.7, Device Posture Profiles are applied to devices connecting to your network behind a Socket. This lets you apply the same Device Posture Profiles, regardless of the device's physical location. For example, a sales executive works two days in the office and three days remotely. The Device Posture Profile is applied to their device whenever and wherever they connect to Cato.

Prerequisites

These are the minimum version Client requirements for Device Checks. See Working with Specific Device Checks and Features for specific details about Device Check.

Device Check

Windows

macOS

Linux

iOS

Android

Anti-Malware

5.2

5.2

5.1

   

Firewall

5.4

5.2

5.1

   

Disk Encryption

5.5

5.6

     

Patch Management

5.5

5.2

5.2

   

Device Certificate

5.5

5.4

5.1

5.3

5.0.1.115

DLP

5.9

5.4.3

5.2

   

Cato Client Version

5.0

5.0

5.0

 

 

Running Process

5.11

5.7

 

 

 

Registry Keys

5.11

 

 

 

 

Property List (plist)

 

5.7

 

 

 

Device Checks applied for users in an office

5.7

       

An empty box indicates the Device Check is not supported on the Operating System.

Known Limitations

  • After creating a Device Check, refresh the page so that the new Check can be included in a Device Profile

Preparing to Use Device Checks

Each Device Check can include these settings:

  • One Device Test Type (for example, Anti-Malware or Firewall)

  • A vendor, product, and version (for all checks apart from Running Process, Registry Key, and Property List)

    • You can choose any version, a specific version, or a minimum version (greater than)

      Note: In a Firewall device check, if you select Apple's macOS built-in firewall, the version number refers to the macOS version number

    • For Anti-Malware, Firewall, Patch Management, and DLP Device Posture checks you can create a general Check for any supported vendor or product. For example, you can create a Check to allow access to a device with any of the supported Anti-Malware solutions installed. For a list of supported vendors and products, see the drop-down lists in the Vendor section of the New Device Check panel.

Configuring Device Checks

Device Checks define the criteria a device must meet to connect to the network. After creating a Check, add it to a Device Profile to enforce the posture requirements.

To configure a Device Check:

  1. From the navigation menu, select Access > Device Posture.

  2. Select the Device Checks tab.

  3. Click New. The New Device Check panel opens.

    DeviceChecksPanel
  4. Configure the settings for the Device Check.

  5. Click Apply and then click Save.

Configuring the Device Profiles

After creating a Device Check, you can add it to a Device Profile to be included in rules in the Client Connectivity Policy or firewall policy to enforce the posture requirements.

DeviceProfiles

To configure a Device Profile:

  1. From the navigation menu, select Access > Device Posture.

  2. Click the Device Profiles tab.

  3. Click New.

    The New Device Profile panel opens.

  4. Configure the settings for the Device Profile, and add the required Device Checks (that you created in the previous section).

  5. Click Apply and then click Save.

Creating a Profile with Multiple Checks

When you create a Device Profile with multiple checks there is an AND relationship between them. This means that a device must meet the requirements of all the Device Checks to apply the rule action to the device.

The following example shows the Sample Device Profile which includes these checks:

  • Patch Management - Sample Patch MGMT

  • Disk Encryption - Sample Disk Encryption

Device_Profile_FW_AM.png

Working with Specific Device Checks and Features

Important information about specific Device Checks and features are outlined in the following sections.

Working with Device Certificate Checks

You can create Device Checks for certificates that are installed on the end-user device that is defined for your account. Use the Device Authentication page (Access > Client Access > Device Authentication) to upload signing certificates for your account. The Check validates that there is a certificate installed on the device that matches one of the signing certificates defined for your account.

Working with Disk Encryption Checks

You can define one or more drive paths that are encrypted (the entire root path is encrypted, for example, C:\). Only software-based encryption is supported (hardware-based encryption is not supported).

For devices with multiple partitions, you can specify which partition is encrypted. When you define multiple drive paths for a device, the Check validates that all paths are encrypted.

Working with Cato Client Version Checks

You can create Device Checks for the Client version installed on the end-user device.

  • To block a specific Client version, use the Block operator

  • To allow a specific Client version, use the Equals or higher operator

Working with the Running Process Checks (EA)

Running Process Checks are supported on Windows and macOS devices.

Running Process Checks on Windows Devices

You can create a Device Check to verify that a process is running on the device and is signed by the specified Thumbprint. To configure this Check, you can include either the process name or the process path and the Signer Certificate Thumbprint.

To identify the Signer Certificate Thumbprint:

  1. Right-click on the process and select Properties.

  2. On the Digital Signatures tab, select the required certificate and click Details.

    The Digital Signature Details window is displayed.

  3. Click View Certificate.

  4. On the Details tab, click on Thumbprint.

    The Signer Certificate Thumbprint is displayed.

    Thmprint.png

Note: The process name and process path are not case-sensitive.

 

Running Process Checks on macOS Devices (EA)

You can create a Device Check to verify that a process is running on the device and is signed by the specified Team ID. To identify the Team ID, in the terminal run the command codesign followed by the full process path. The Team ID is returned. For example:

macosprocess.png

Process names can contain unicode characters and are case-sensitive.

Known Limitations of Process Checks on macOS Devices
  • Checking for Applications is not supported, the full process path must be included in the configuration

Working with the Registry Key Checks

To create a check for a Registry Key you need to specify the:

  • Full Registry Key Path
  • Value Name (you can choose to check for the default value or a specific value)
  • Value Data (you can choose to check for any value or a specific value) 

To identify the Value Name and Value Data, in the Registry Editor, double-click on the Registry Key you are checking for. In the example below the Key Value Name is start_minimized and the Key Value data is 0.

Reg_Key.png

 

Working with the Property List Checks (EA)

To create a check for a Property List file (plist) you need to specify the full file path of the plist to check for. You can configure the Check to verify that:

  • A specific key exists in the plist by selecting Any Value

  • A specific key and value exist in the plist by selecting Specific.

To identify the key name and value within a plist, open the file with a text editor. In the example below, the key name is Label and the value is com.catonetworks.mac.CatoClient.helper.

plist.png

Known Limitations of Property List Check

  • The path name can only contain UTF-8 characters

  • plist files located in user folders are not supported

Working with Real-Time Protection

In the Criteria section, you can also choose to enable Real time protection, and a connected device is continuously verified that it matches the Device Check.

Working with Unsupported Cato Clients

Sometimes you need to accommodate Clients in your organization that currently don't support Device Posture, and allow these Clients the access the network. When you configure a Device Check, the Criteria section lets you choose the behavior for Clients that don't support Device Posture.

When an unsupported Client matches the settings for a rule except for the profile, these are the behavior options:

  • Skip the Device Check, and allow unsupported Clients to connect to the network

  • Block unsupported Clients because they can't meet the requirements of the Device Check

We recommend that you minimize the scope and impact of Device Checks that allow unsupported Clients in your organization. The fewer unsupported Clients that are allowed, the stronger the Client Connectivity Policy is.

Was this article helpful?

0 out of 0 found this helpful

0 comments

Add your comment