Define risk assessment criteria

One of the first Device Posture tasks to perform is to establish the criteria that determine the risk of each user device. You can define these criteria by configuring risk tiers and risk tags that can then be added to the application access control rules (ACLs).

Risk tiers

Device Posture uses defined criteria to assign devices to one of three risk tiers:

• Low
• Medium
• High

Risk tiers are hierarchical and evaluated in order from low to high. Any device not matching low and medium will fall into the high-risk tier category.

Any device that is reporting signals to the EAA back end (for example, a device with properly operating EAA Client) is assigned to one and only one risk tier. Devices that are not reporting signals to the back-end systems are considered to be unmanaged. Unmanaged devices do not appear in device inventory reports.

You define the criteria that Device Posture uses to assign a device to the low or medium tiers. All devices not satisfying the criteria for these tiers belong to the high tier.

The following are default criteria for the low and medium tiers:

• Low tier default criteria for Windows,macOS, and Ubuntu devices:

  • Anti-malware profile is Any Vendor
  • Firewall status is good
  • OS version is latest or latest+

• Medium tier default criteria for Windows,macOS, and Ubuntu devices:

  • OS version is latest, latest+, up-to-date, or up-to-date+.

Before any configuration changes, you can see a preview of expected changes to your device population. The number of devices impacted in each tier displays in parentheses; green parenthesis indicates the number of devices that will be added to the tier by the configuration change, while red parentheses indicate the number that will be subtracted. When you click Save Rule, you overwrite new criteria and rules. You can check the Device Posture dashboard to see the updated risk tier classification.

The assignment of a device to a risk tier is not static. It is subject to change at any time based on tier or tag definitions and on the periodic retrieval of signals from each device.

See Define device risk tiers.

Risk tags

You can optionally create risk tags to classify and group devices. The criteria used are the same as those used for risk tiers. While a device can only be in one risk tier at a time, a device may be in one or more risk tags.

You can use risk tags alone or in combination with risk tiers as criteria in the application access control rules. Tags are also a convenient way for administrators to track device characteristics in the device inventory.

See Define device risk tags.

Versions

You can enter the required versions of operating systems, browsers, EAA Clients, and ZT Clients. These specifications are in turn used as criteria in risk tier and tag classification.

See Define versions

Anti-malware profiles

With this capability, you can configure anti-malware profiles that check for the presence of installed anti-malware software on a device. In the configuration settings, you have to specify the desktop OS platform and the anti-malware vendor. This enables Device Posture to check collected signals against the profile parameters and evaluate the security posture of your devices.

EAA Device Posture also supports no-English Anti-malware vendors in Windows Security Center for the following vendors in these languages:

See Configure an anti-malware profile to learn how the active status corresponding to macOS and Windows OS is defined.

Device certificates

With certificate profiles, you can make more informed access decisions and exercise wider control over devices. Certificate profiles allow you to verify various aspects of device certificates found on a device. You may configure a certificate profile to identify devices that possess certificates that are signed by a Certificate Authority (CA) that you provide along with verifying other parameters. After you define certificate profiles, you may configure them as criteria in risk tiers and tags.

📘

Note

This feature does not verify that the browser or application used for accessing your protected applications is using the certificate specified as part of certificate profiles. It does verify the presence of certificate profiles and other parameters on the device.

For Ubuntu, device certificates are detected for certificate profiles only if they are configured in these two forms:

1. Using the NSS-Shared DB in Linux Cert Management.
   a.The private key must be added as an identity and must show up when you run certutil -d sql:$HOME/.pki/nssdb -K
   b. A certificate must exist with the same alias as the private key from the above command.

2. Certificates are stored as flat files in a directory.
   a. Only $HOME/.certs directory is supported.
   b. Only container formats with these extensions are supported, .p12, .pfx
   c. If the organization manages certs and keys separately, EAA supports the following formats - .key for private keys and .crt for certificates
   d. For private keys, EAA only supports PKCS1 and PKCS8 private keys encoded in PEM format. We support rsa, ecdsa, and ed25519 private keys
   e. For certificates, EAA supports any PEM encoded valid x509 certificate.

For more information, see Configure a certificate profile.

Integrations

You can integrate signals collected from ​Akamai​ Secure Internet Access Enterprise (SIA), CrowdStrike, and VMware Carbon Black, and use them as criteria in risk tiers and tags.

Note: SIA is not supported on Ubuntu.

See Collect signals from SIA, Integrate with CrowdStrike and Integrate with VMware Carbon Black.

After you have configured integrations, the new signals may be used as criteria when defining risk tiers and tags. The new signals will also be visible as part of device details and in inventory reports.