In some scenarios, the Controller of an AppGate ZTNA Collective may not receive data from the Risk Engine. To keep your company's resources secure when this happens, AppGate ZTNA supports a configurable fallback risk level.
Three communication error scenarios can interrupt data flow between AppGate ZTNA and ZTP:
Rule/Adapter not working
Device risk data not available
ZTP not reachable
This section explains how to configure a fallback risk level for each scenario in the AppGate ZTNA admin UI.
You can set a fallback risk level to high, medium, or low. If any of the three scenarios occurs and you have not changed the default configuration, the fallback risk level defaults to high. Any device or user attempting to connect to a resource is treated as high risk.
The appropriate fallback risk level for each scenario depends on your environment and your assessment of each failure condition. To inform your decision, consider how the Risk Engine and AppGate ZTNA Controllers interact:
An existing AppGate ZTNA Collective connects to a ZTP account, and one or more risk rules are created in the Risk Engine.
The Risk Engine collects security posture information from a third-party service through an adapter.
When an end user connects to AppGate ZTNA, the Controller requests a risk level from the Risk Engine. The Risk Engine evaluates all active risk rules and returns a single risk level.
The Controller uses that risk level, together with its analysis of entitlements and policies, to grant or deny the end user access to resources.
This communication flow applies to both connected and hosted Collectives, as does the fallback risk level configuration.
Consider the trade-offs when choosing a fallback risk level:
High: Closes access to resources. Users and devices are blocked from policies and entitlements until the issue is resolved.
Low: Opens access to resources. All users and devices are treated as low risk until the issue is resolved.
Medium: Balances security risk against end-user disruption while the issue is resolved.
The following sections describe each communication error scenario in detail.
Scenario 1: Rule/adapter not working
The communication between the adapter in ZTP and the third-party service has failed. Potential causes include:
The credentials for the third-party service have changed.
The permissions for the adapter to access resources have changed.
The endpoint location has changed—for example, the third-party domain, region, or URL has moved.
The third-party service is offline or unavailable.
The route from the Risk Engine to the third-party service is disrupted.
The adapter is malfunctioning.
Scenario 2: Device risk data not available
The adapter in ZTP successfully communicated with the third-party service, but the third party returned no security posture information. Because the Risk Engine received no data, it cannot calculate a risk level for the Controller. Potential causes include:
The device or end user was recently added to the third-party service and is not yet reporting data.
The device or end user is unknown to the third-party service. The adapter is requesting data from a service that does not cover that device or user. In this case, create a new risk rule configured with the appropriate adapter.
There is a mismatch in device or end-user identifiers between AppGate ZTNA and the third-party service. If identifiers were updated in the third-party service, update them in the risk rule as well.
Scenario 3: ZTP not reachable
The Controller cannot connect to ZTP. Potential causes include:
The route from the Controller to ZTP is disrupted—for example, a new firewall is blocking communication.
The Risk Engine is temporarily offline.