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.
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.
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.
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.
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.
-
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.
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.
To configure a Device Profile:
-
From the navigation menu, select Access > Device Posture.
-
Click the Device Profiles tab.
-
Click New.
The New Device Profile panel opens.
-
Configure the settings for the Device Profile, and add the required Device Checks (that you created in the previous section).
-
Click Apply and then click Save.
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.
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:
Important information about specific Device Checks and features are outlined in the following sections.
You can create Device Checks for certificates that are installed on the end-user device that is defined for your account. Use the Signing certificates page (Access > Client Access > Signing certificates) 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.
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.
Running Process Checks are supported on Windows and macOS 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.
To identify the Signer Certificate Thumbprint:
-
Right-click on the process and select Properties.
-
On the Digital Signatures tab, select the required certificate and click Details.
The Digital Signature Details window is displayed.
-
Click View Certificate.
-
On the Details tab, click on Thumbprint.
The Signer Certificate Thumbprint is displayed.
Note: The process name and process path are not case-sensitive.
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:
Process names can contain unicode characters and are case-sensitive.
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.
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.
These plist data types are supported:
-
Strings
-
Integers
-
These nested data types:
-
String
-
Integers
-
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.
12 comments
Updated to include support for endpoint Firewall Device Checks
Updated to include support for:
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?
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.
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.
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?
Need jailbreak and root detect
Hi wwebsterSA,
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.
Hi Makara Sakolvaree,
To request new features, please open an RFE. For more information, see Requesting New Features (RFEs).
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?
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
Thanks Michael, the link helped.
Please sign in to leave a comment.