The Trust Algorithm

Wait, doesn’t Zero Trust mean no trust?

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 implicit trust and explicit trust in this case being that the attributes of the actor being evaluated are explicitly verified as opposed to being implicitly assumed to be valid.

graph LR;
    A[Untrusted]
    B[Trusted]
    C[Trust Algorithm]
    D([Continuous evaluation])
    A--->C--->B
    D-.->B
    C-.->D

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 algorithm which ultimately gives a binary response to allow or reject access.

Note that it is possible to run multiple iterations of trust algorithm 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 algorithm 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:

graph LR;
    A[User SignIn]
    B[Risk calculation]
    C[Policy evaluation]
    D[Access granted/rejected]
    E([ZTP Risk score])
    F([User claim risk score])
    G([Asset sensitivity])
    A--->B--->C-->D
    E-.->B
    F-.->B
    G-.->C

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:

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.

graph LR;
A[High Risk User]
1[High Sensitivity App]
2[Medium Sensitivity App]
X([AAD CAP])
Y([Appgate SDP])
A-->X-->|denied|Y
Y-.->|denied|1
Y-.->|denied|2

graph LR;
B[Medium Risk User]
1[High Sensitivity App]
2[Medium Sensitivity App]
X([AAD CAP])
Y([Appgate SDP])
B-->X-->|allowed|Y
Y-->|denied|1
Y-->|user action|2

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.

Recommended Reading

• NIST SP-800 for Zero Trust Architecture
• Appgate SDP Dynamic Access
• Azure AD Conditional Access Overview