Understanding Risk Engine Settings in Appgate SDP
This article discusses the risk engine settings found in the Appgate SDP (Software Defined Perimeter) admin UI. These settings specifically pertain to fallback risk level score values, which are crucial for evaluating the risk associated with user or device connections. By default, all fallback scores are set to "high." This means if any errors occur, the user or device attempting to connect will be considered high risk.
Overview of Risk Engine Functionality
The risk engine plays a vital role in determining access permissions. When a user attempts to access a resource, they log in using their Appgate SDP client, which pings the controller. The controller then requests a risk score from the risk engine service based on predefined risk rules. These rules gather data, such as security posture information, from third-party services to calculate risk scores. This information is cached while awaiting requests from the controller.
Fallback Risk Levels
There are three primary scenarios in which fallback risk levels come into play:
Scenario 1: Communication Break Between Risk Rule and Adapter
If the connection between the risk rule and the adapter fails, it may occur due to several reasons:
Credentials to the third-party service have changed.
Tokens or secrets used for access have expired.
Permissions for the adapter have changed.
The endpoint for the third-party has changed.
The third-party service is offline or unavailable.
There is an internal malfunction of the adapter.
Scenario 2: Device Risk Data Not Available
This scenario occurs when the adapter communicates successfully with the third party, but the requested data for a user or device is unavailable due to:
The user or device being recently added to the third party.
The third party not immediately reporting security posture data.
The user or device being non-existent in the third party's records.
A mismatch in identifiers between SDP and third-party systems.
Scenario 3: ZTP (Zero Trust Platform) Unreachable
If there is a disruption in the communication between the controller and the risk engine service, it can occur due to:
Network disruptions affecting the route to ZTP.
Firewall rules blocking access.
The risk engine service being temporarily offline.
Configuring Fallback Risk Levels
Default fallback risk levels are set to "high." Administrators can change these settings based on their environment and risk assessment. Lowering the fallback risk may lead to a fail-open scenario, meaning users and devices might be allowed access even when their risk is deemed high. Care should be taken before making such changes as it could significantly alter access control policies.
Conclusion
Understanding and configuring fallback risk levels is essential for maintaining security in your Appgate SDP environment. For detailed instructions regarding these settings, refer to the Appgate Zero Trust platform user guide.
FAQs
What are the fallback risk level score values in Appgate SDP?
Fallback risk level score values determine how a user or device is classified in case of connection errors, with default settings typically set to high.
How does the risk engine calculate risk scores?
The risk engine calculates risk scores by gathering security posture information from third-party services using predefined risk rules.
What are the three primary fallback risk scenarios?
The three primary fallback risk scenarios are communication breaks between risk rules and adapters, unavailable device risk data, and not being able to reach the ZTP (Zero Trust Platform).
What happens if the fallback risk level is set to low?
Setting the fallback risk level to low could lead to a fail-open scenario, allowing access even when the associated risk is high.
Where can I find detailed instructions for configuring fallback risk levels?
Detailed instructions for configuring fallback risk levels can be found in the Appgate Zero Trust platform user guide.