Risk-based Access Controls

Just because a device is sanctioned does not imply that the device is inherently safe.

Besides a device's risk posture at activation time into Trusted Access, a device's risk state is not static: it will fluctuate throughout the lifetime of the device as it installs software, and vulnerabilities in that software is discovered and subsequently patched.

A device that becomes "unsafe" isn't in-and-of itself a risk (it is a hunk of plastic and silicon afterall), but it presents risk to the infrastructure and data it has access to both locally and over the network.

Therefore, if a device becomes "risky" or unsafe, Trusted Access is able to automatically reduce the resources the device is able to access on an application-level. We call this "risk-based access control."

The Jamf Trusted Access solution defines several mechanisms to deliver risk-based access control:

• Network-based access control
• Partner compliance-based access control

Network-based Access Controls

With network-based access controls, IT is able to define the threats that constitute risk to their organization into a Secure/Low/Medium/High rating, and then granularly allow or deny access to sensitive resources via Private Access based upon those risk levels.

This approach is very generic, operating at Layer 3 (TCP/UDP) in the network, allowing enforcement to take place for virtually any network-based application (HTTP, Web, SSH, RDP, VoIP, etc.).

To configure network-based risk policy, follow these steps:

1. Customize your organization's security policy risk levels in RADAR.
2. For each of your sensitive applications available via a Private Access Access Policy define the tolerable device risk level in the Security tab.

You can monitor any given device's risk level in the devices view of RADAR.

End users will receive push notificaitons to their device when they are blocked by a risk-based access policy. They can then use the Jamf Trust app installed on their device to see their device's outstanding threats to regain access to blocked resources.

As users remediate their threats, their device's risk score is updated and access is automatically recalucated based upon their device's new risk posture.

Partner Compliance-based Access Controls

Several partners allow or block access to applications and data based upon metadata signaled to them via Jamf.

While not all approaches are the same, they all ultimately allow the partner to determine:

• Whether or not the device is managed by the organization's Jamf Pro instance.
• Whether or not the device is compliant based upon logic in the partners tool or in Jamf Pro.
• Whether or not the device is secure per Jamf's security evaluation engine.

Using this information, the partner is then able to apply contextual access policies for login requests to applications they manage.

Partner integrations include:

• AWS Verified Access for macOS: Provides protection of AWS workloads through contextual zero trust policies informed by Jamf metadata including device management state and risk score.
• Microsoft Intune / Endpoint Manager: Device metadata from Jamf Pro is sent to Intune/MEM, and macOS Compliance Policies are used to set the device into a "Compliant" or "Not Compliant" state. This state is then used in Conditional Access Policies to drive allow/block access decisions for that device.
• Google BeyondCorp: The integration allows the definition of two Smart Groups: All Devices and Compliant Devices. The membership of these groups can be defined using your own requirements driven by the advanced contextual group capabilities of Jamf Pro. Based upon group membership, Google BeyondCorp Context-Aware Policies will allow or deny access based upon membership in the "Compliant" devices group.