The Trust Algorithm

Wait, doesn't Zero Trust meant no trust?

02 Feb 2023 909 words 5 minutes

/posts/ztTrustAlgo/ztFeatureTrustAlgo.webp

A common misconception about zero trust is that there should be no trust. Rather, the philosophy of zero trust directs us to start with zero implicit trust on an actor, move it through the process of establishing explicit trust until it reaches the required threshold, and perform continuous evaluation thereafter. The difference between imlicit trust and explicit trust in this case being that the attributes of the actor being evaluated are explicilty verified as opposed to being implicitly assumed to be valid.

Therefore any system responsible for controlling access must have a way to implement a trust algorithm. In the NIST SP-800 for Zero Trust Architecture this is described as the “thought process” of the “brain” which is the policy engine. For effective zero trust based access control, the policy engine must be able to take input from several sources. The sources can be context of the access request, attributes and history of the actor, context of the requested asset and threat intelligence. This is illustrated in the diagram below taken from the ZTA document. The weight of each component contributes to the scoring of the alogrithm which ultimately gives a binary response to allow or reject access.

Note that it is possible to run multiple iterations of trust alogrithm to arrive at usecases such as “step-up authentication” or “restricted access”. For example, the first iteration may reject access, but a condition can be triggered on rejection to enforce reauthentication. The next iteration of the trust algorithm can then factor the reauthentication and potentially allow the access. The NIST document provides further details about the trust alogrithm types.

“Show me the money”

The theory is nice, but practical implementation is what drives security forward. There are several solutions that use aspects of this trust algorithm to control access. Given below are a few practical implementations using commercially available solutions

Appgate SDP

Appgate SDP enables organizations to adopt a Zero Trust approach to network security, providing granular, context aware access control for distributed cloud and hybrid environments. Appgate SDP introduces the concept of the 6-layer trust model with separate verification steps that extend beyond just sign-in allowing further verification to be required at time of use - when an attempt is made to connect to a specific resource.

Within the Appgate SDP admin UI, you can configure the Risk Matrix as shown below. This matrix drives the access controls based on the user risk score and the sensitivity of the protected resource.

To configure how the user risk score is calculated, you can rely on the Appgate ZTP platform, which itself will integrate with solutions like CrowdStrike Falcon Insight, McAffee MVISION etc. You can also use user claim scripts which are small scripts that run on the SDP collective to query parameters. An example of using this would be to query the AzureAD Risky User api to determine the risk level of the user. Finally, the policy definition uses the access criteria to allow/deny access as per the rules defined. The trust algorithm for this kind of a setup in Appgate would look like this:

AzureAD and Conditional Access Policies

Conditional Access Policies in AzureAD are a set of rules that can take input from several sources to make a decision to grant/deny access. Under advanced settings, the grant access can also enforce additional controls such as preventing downloads, copy/past of data etc. Common signals that Conditional Access can take in to account when making a policy decision include the following signals:

User or group membership
- Policies can be targeted to specific users and groups giving administrators fine-grained control over access.
IP Location information
- Organizations can create trusted IP address ranges that can be used when making policy decisions.
- Administrators can specify entire countries/regions IP ranges to block or allow traffic from.
Device
- Users with devices of specific platforms or marked with a specific state can be used when enforcing Conditional Access policies.
- Use filters for devices to target policies to specific devices like privileged access workstations.
Application
- Users attempting to access specific applications can trigger different Conditional Access policies.
Real-time and calculated risk detection
- Signals integration with Azure AD Identity Protection allows Conditional Access policies to identify risky sign-in behavior. Policies can then force users to change their password, do multi-factor authentication to reduce their risk level, or block access until an administrator takes manual action.
Microsoft Defender for Cloud Apps
- Enables user application access and sessions to be monitored and controlled in real time, increasing visibility and control over access to and activities done within your cloud environment.

The trust algorithm for conditional access policies looks like this:

/posts/ztTrustAlgo/conditionalAccess.webp — AzureAD Conditional Access Policies

These two solutions can also be combined by making AzureAD the Identity provider and SSO service for Appgate. This approach enables chaining of the trust algorithm and reduces the burden of security check on the downstream systems.

In conclusion…

Zero Trust is a philosophy, approach, framework and consists of reference architectures. It is not a silver bullet and certainly not a technology. However, implementing ZT is made possible and easier using the right set of technologies. If the technology cannot support a trust algorithm, cannot take input and signals from multiple sources, cannot make dynamic policy decisions, cannot perform monitoring, then it cannot truly implement a Zero Trust approach. The corollary of course is, even the right technology, if implemented without a trust algorithm, cannot deliver ZT based access control either.