Creating Device Posture Profiles and Device Checks

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.

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 Supported Device Checks 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 Users Dashboard.

Device Checks in an Office

Note: Supported from:

  • Windows Client v5.7
  • Linux Client v5.3

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.

Supported Device Checks

These are the minimum version Client requirements for Device Checks. See Working with Specific Device Checks and Features for details about each 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

  5.3    

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

Known Limitations
  • After creating a Device Check, the page needs to be refreshed so that the new check can be included in a Device Profile

  • In an office, the Client checks the Device Posture every 10 minutes. The configuration set for Client periodic checks do not apply

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.

image1.png

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.

Configuring Periodic Checks

Device Checks assess the posture of a device during the Client connection process. To continue to assess the posture of a device after the Client is connected, you can enable the Device Check to run multiple times and configure the frequency of the check. By default, period checks run every 10 minutes.

To understand the user experience if a period check fails, see Configuring the Client Connectivity Policy.

Period_Check.png

To configure periodic checks:

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

  2. Click the Settings tab.

  3. Set the frequency of the check in minutes.

  4. 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

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 that it is signed by the specified certificate. To configure this Check, you can include either the process name or the process full path and the Signer Certificate Thumbprint.

You can identify the Signer Certificate Thumbprint within the Properties of the process. For example, for the process CatoClient.exe the Signer Certificate Thumbprint is 81d821c152fa98db1c950b87d435122e5a0b451d.

Thmprint.png

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.

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

Running Process Checks on macOS Devices

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, for the process /Applications/CatoClient.app/Contents/MacOS/CatoClient, the Team ID is CKGSB8CH43:

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

  • Checking for processes that do not have a Team ID, for example, internal macOS processes, are not supported 

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)

Note

Note: Non-ASCII characters for registry keys or value names are not supported.

All data types are supported. In a Multi-sting Registry Key, separate the lines with a vertical bar symbol (| ). The format of the data in a Binary Value or Binary Value type is the HEX representation of the first 16 bytes, for example 0102030405060708090A0B0C0D0E0F10.

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

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

Supported Property List Data Types

These plist data types are supported:

  • Strings

  • Integers

  • These nested data types:

    • String

    • Integers

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 of the Anti-Malware check, 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?

2 out of 3 found this helpful

12 comments

  • Comment author
    Yaakov Simon

    Updated to include support for endpoint Firewall Device Checks

  • Comment author
    Yaakov Simon

    Updated to include support for:

    • New Device Checks: Patch Management, Disk Encryption and Certificate
    • macOS Client v5.2 for Anti-Malware, Firewall, and Patch Management checks
  • Comment author
    Koen Vandenabeele

    It is not clear whether device profiling does or does not work if a workstation is only running the SDP client as user agent.

    Do you need to be connected or in office mode for the device checks to be performed?

  • Comment author
    Michael Goldberg

    Hi Koen Vanderschelde,

    The device checks run during the Client connecting process. If the Client doesn't connect, the checks to do not run. 

    Behind a site,  the device checks only run on Windows Client v5.7 and higher. 

  • Comment author
    Srecko srecko.anzic

    I don't understand the Working with Cato Client Version Checks part. If we try to use Patch Management there is no Cato under the Vendor dropdown.

  • Comment author
    Will Webster SA

    Period checks are only ever referenced but not really explained.  If I set periodic check to 0, meaning it never periodically checks, is it still atleast checking at connection time?

  • Comment author
    Makara Sakolvaree

    Need jailbreak and root detect

  • Comment author
    Michael Goldberg

    Hi Will Webster SA,

    Device checks run as part of the Client Connectivity Policy every time the Client Connects. For more information, see Understanding the Cato Client Connection Flow.

  • Comment author
    Michael Goldberg

    Hi Makara Sakolvaree,

    To request new features, please open an RFE. For more information, see Requesting New Features (RFEs).

  • Comment author
    Sebastian Kempf (PRIA)

    Hi, it seems like there is no detailed event entry if a client fails the device posture. I can find a block event, but it doesn't outline why. Am I looking at the wrong place or is this a feature request?

  • Comment author
    Michael Goldberg

    Hi Sebastian Kempf (PRIA),

    If a Client fails a Device Posture check an event is created with the Client Connectively Policy Sub-Type. For more information, see Understanding Events for the Client Connectivity Policy 

  • Comment author
    Sebastian Kempf (PRIA)

    Thanks Michael, the link helped.

Add your comment