Zero Trust

On your journey towards a zero trust architecture, you might find that parts of your infrastructure can’t implement zero trust principles. This guidance looks at why this might be the case, and suggests two ways organisations can enable access while maintaining the security benefits of zero trust for the whole system. We refer to the resulting architecture as a mixed estate.

When it isn’t possible or practical to implement zero trust across all of your estate, you have the option to build a mixed estate. This is when part of your architecture is implementing zero trust, but you still need to access systems that can’t implement zero trust principles.

It’s recommended that your estate implements zero trust principles wherever possible, and that access outside of that is limited to defined segments of systems not part of your zero trust architecture. To establish trust in the systems that are accessing less trusted systems, your zero trust architecture should include your core services and client devices. This provides all the benefits and security of zero trust, while still enabling business activities on systems that can’t use zero trust.

Conventional systems can be integrated into a mixed estate to enable users within your zero trust estate to access them. Two ways to build a mixed estate are by using:

• a zero trust proxy or
• a managed virtual private network (VPN)

A zero trust proxy is often used to mediate connections in a native zero trust architecture, but can also be used in a mixed estate, where it can sit between end user devices and conventional systems. Clients connect to the proxy, and the proxy then manages access to the applications, in line with zero trust policies. Using a zero trust proxy allows for secure remote access to applications that can’t natively support zero trust.

How do they work?

A zero trust proxy usually comes in two parts: a proxy server and a proxy connector.

A proxy server acts as a policy enforcement point and controls access to applications using a least privilege model. To make access decisions, the policy enforcement point communicates with the policy engine. Once the policy engine grants a client access to an application, the proxy will forward traffic from the client to the proxy connector.

A proxy connector enables a secure bidirectional channel to the proxy server, typically using TLS. This then provides data-in-transit protection for clients that are accessing applications via the proxy server, which don't natively support secure communications.

Connectors must be deployed in a location where the application is visible and which also allows for an outbound connection to the proxy server. Connectors can be hosted on a separate machine to the application, which might allow for some network segmentation where the connector is only allowed to access the application it serves.

It's also important that all traffic to that application goes through the proxy 

connector, and that there are no shortcuts to the application via an insecure protocol or authentication method.

An application should only accept connections via the proxy connector when this can be enforced at the network layer using a firewall.

Example of the high-level architecture of a common deployment of a zero trust proxy

As the proxy is responsible for providing zero trust access to your legacy systems, you should make sure it has certain features:

• It should support secure and modern authentication, such as SAML 2.0, OIDC or FIDO2, and be able to communicate with your policy engine, using multiple signals to make an access decision. This helps achieve NCSC zero trust principle 4: use policies to authorise requests and zero trust principle 5: authenticate and authorise everywhere. Users should be authenticated before they are allowed to communicate with the application and shouldn’t be allowed to before then.
• There should be secure communication with the proxy. Connections either side of the proxy server must be secure, so it's important that the proxy server, proxy connectors and end user device support secure communication protocols such as TLS. This is in line with the NCSC zero trust principle 7: not to trust any network, including your own.
• Outbound connections from proxy connectors. Ideally a proxy connector will connect outbound to the proxy server to establish a secure bidirectional channel. As the proxy connector creates an outbound connection, no ingress points are created in the network perimeter, which also has the advantage of reducing the attack surface.
• It should be hosted in the cloud, ideally as a higher order offering, such as software as a service (SaaS). This removes the requirement to maintain it because the cloud provider manages it. Cloud hosting also allows for easy integration with any existing cloud-based identity service and policy engine. Our cloud security guidance can help determine whether you should trust a service.
• Access auditing. The proxy server should provide auditing support whenever a device accesses an application or resource. This will help detect if a device is compromised, or if there are unauthorised attempts to access applications. Auditing also allows for user behaviour analytics which you can use as a signal in your policy engines, allowing for more intelligent access decisions. This is in line with the NCSC zero trust principles to focus your monitoring on users, devices and services and assessing user behaviour, service and device health.

• Most zero trust proxy solutions are specific to a set of applications or protocols, for example, some proxies only support web protocols. This can bring added complexity when supporting things like rich client applications. In some niche applications, there might be issues with protocol support.
• A zero trust proxy might not scale well in environments with many applications or solutions, and might even require one proxy per application. This might require more on-premises infrastructure such as virtual machines to host the proxy connectors, which adds a support and maintenance overhead.
• You might also need to consider how you make sure that all traffic is routed through the zero trust proxy and that there are no shortcuts using insecure protocols or authentication methods. This might require new configurations on your on-premises network, such as new firewall rules, which limit traffic to the proxy connector and the application only.

A zero trust proxy aims to provide a policy enforcement point for your conventional or legacy applications. This provides secure remote access to applications using zero trust practices, which are otherwise supported. This could be a good solution for the majority of use cases, but you will need to check protocol support and understand if they scale well for the number of applications in your environment.

Managed VPN

A managed VPN allows traffic to be selectively sent outside of the tunnel based on configured rules. To support a mixed estate, traffic to services supporting zero trust can be routed outside the tunnel, allowing for standard zero trust practices. Traffic destined for legacy systems can be routed inside the tunnel, allowing secure access to applications that are unable to implement the zero trust principles.

When they are suitable

A VPN provides data-in-transit protection for traffic to applications which can’t support secure protocols. Using a managed VPN can improve the user experience, availability and reduces maintenance workload, as only traffic going to legacy systems transits over the VPN.

A managed VPN could be a first step while your zero trust enabled applications grow in numbers.

The NCSC provides further guidance on VPNs and walled garden architectures.

The high-level architecture of a common managed VPN deployment

Things to consider with a managed VPN

• When using a managed VPN in a traditional network, it might mean that some applications continue to rely on the inherent trust of the network.
• Applications that don't support zero trust also can’t mediate access via a policy engine using a number of signals, and they can’t verify every request to access data or services. This carries risks, such as increased risk of lateral movement.
• Having a managed VPN may require less rework to your architecture because there you don’t need to install new zero trust proxies or create new firewall rules (assuming you already have a VPN in your architecture). A VPN will also support secure tunnelling of a wide range of protocols. This is an advantage over some zero trust proxies, where some niche protocols might not be supported.
• It's also important to consider how you will administer and support the managed VPN, as it creates an additional maintenance overhead. Incorrect configuration of the managed tunnel could result in information leakage.
• Using a VPN typically funnels traffic to a central point in the network, and will slightly increase latency. This could be an issue for latency sensitive applications at scale, such as video calling.
• A managed VPN might be more suitable at the start of your zero trust journey, when you only have a few applications capable of implementing zero trust principles.

The right approach for you

Building a mixed estate is complicated, but this guidance provides a useful starting point, and will help you on your zero trust journey

Each approach has its merits. A managed VPN follows a more traditional approach to remote access, so it's well understood, while the zero trust proxy is an innovative way of providing remote access, while removing some of the disadvantages of remote access solutions.

There is no solution that will be suitable for all circumstances, so it's important to consider how a certain technology fits the needs of your organisation. Pay particular attention to the scale of any solution and the support for certain protocols when deciding your approach.

There might also be approaches not covered in this guidance which will work better for your use case. Either way, it's important to find a solution that supports your journey towards zero trust while maintaining the same level of security for systems that can’t implement the zero trust principles.