Eight principles to help you design and deploy a zero trust architecture.
BETA: This guidance is a draft that we'd like to share with the community for comment.
Our ALPHA Guidance can be found here
[Our blog|[https://www.ncsc.gov.uk/blog-post/zero-trust-principles-beta-release] introduces this guidance and covers our approach.
If you have any feedback or ideas you can create an issue or if you'd like to contribute create a pull request.
You can also e-mail us on zerotrust@ncsc.gov.uk
Network architecture is changing. More services are moving to the cloud and there is continued growth in the use of Software as a Service (SaaS). Meanwhile, many organisations are embracing flexible working, with staff connecting from multiple devices in a variety of locations.
The traditional network perimeter is disappearing and with it, the value of traditional defences. Zero trust is a network architecture designed to cope with these changing conditions. The 8 principles outlined in this guidance will help you to implement your own zero trust network architecture.
In a zero trust architecture, inherent trust is removed from the network. Just because you're connected to a network, doesn't mean you should be able to access everything on that network.
It is common in breaches to see an attacker gain a foothold on a network and then move laterally, because everything on the network is trusted. In a zero trust architecture, the network is treated as hostile.
If you remove trust from the network, you must instead gain confidence in your users, device, and services. This is achieved by building trust into the user's identity (through authentication), device health, and the services they access (authorisation).
For zero trust to be effective, each connection to a service should be authenticated and the device, user and connection authorised against rules and policies. Theses polices assess the amount of confidence you have in a user and their device, regardless of where the connection request comes from and grant access to resources accordingly.
To enable authorisation decisions, access policies need to be defined, based on who can access which service or data, and under which circumstances.
How much confidence you need to trust a connection depends on the value of data being accessed or the impact of an action being performed. Devices should be inventoried and device health should be based on defined policies (such as encryption, patch levels, etc).
If you are unsure whether zero trust is the correct network architecture for your needs, or if you would like to learn a bit more about zero trust, our network architectures guidance is a good place to start.
This guidance is aimed at a technical audience: Systems Engineers, Solution and Security Architects, and CISOs. The principles are also useful for reviewing architectures when carrying out security assessments or assurance activities.
When implementing your design, these principles can be used as a guide for the features to look for in any specific technologies you plan to use.
Companies or open source projects implementing zero trust related technologies can also use these principles to guide their development and assess which part of the zero trust puzzle they fit into.
Using these principles does not guarantee a secure architecture but should help you to focus your efforts.
IT systems rarely stand still - they change over time. With this in mind, these principles are not intended to be applied once and then forgotten. This is especially important because zero trust architectures are relatively new and still evolving.
You may find you cannot fully meet all these principles at once, as the technology you have in place does not support a zero trust architecture, as described here. In fact, this might be a common scenario, until zero trust technology matures.
Try to be pragmatic in the solutions you choose. It may be the case you still need to support traditional security controls. As your system gradually transitions to zero trust, you should keep these principles on hand
Your architecture should be flexible enough to evolve, meeting changing needs, without impacting users. Consider how you would add new services, move between services, enable and disable features. This flexibility will allow your users to take advantage of new features, but also permit you to quickly respond to new vulnerabilities and threats.
Re-visit your architecture periodically and implement any changes that improve the usability and security of your system.
An existing system architecture can't be replaced overnight.
Deploying the zero trust model to an existing network, regardless of its age or number of legacy services, will require a phased approach, with many iterations. It will take time to get the necessary foundations in place. For example, establishing a strong identity for users and devices or deploying modern authentication across your organisation can be time consuming.
While transitioning to a new architecture, don't start decommissioning traditional security controls before you have implemented and tested your zero trust controls. Due to the nature of a zero trust architecture, this may leave your systems exposed and at considerable risk if they aren't properly configured and tested. For example, don't remove your VPN connection until you are satisfied that the new zero trust architecture is mitigating all the threats the VPN was covering.
Legacy systems may still be hosted using a traditional network architecture, or might not support the features of a zero trust architecture. So, in some environments you may need to manage both a traditional network perimeter and a zero trust architecture. This could involve using a split VPN tunnel to your legacy application or an authentication proxy. When a legacy system is being updated, try to design in support for zero trust.
Even with the luxury of a greenfield environment, the zero trust model can be challenging. Many of the principles outlined below can't be fully satisfied with current, commercially available offerings. As always in security architecture, a risk managed approach is required.
When discussing zero trust architectures, it's useful to have a common vocabulary. Below are some terms used throughout these principles. We've tried to closely align these terms with other sources, to help when discussing zero trust technologies.
-
Access Policy -- A specification of the requirements for access requests to be considered trusted and authorised.
-
Configuration Policy -- Policies that describe configuration options for devices and services.
-
Signal -- A piece of information like device health or location that can be used to gain confidence that you can trust an asset. You will often use a number of signals to make a decision to grant access to a resource.
-
Signal database - A long term store of signals used to make access decisions
-
Policy Engine -- The component that takes signals and compares them with access policies to determine an access decision. A policy engine will often be a 3rd party product or service that can be purchased from a vendor.
-
Policy Enforcement Point -- Mediates requests from a device to a service using the Policy Engine to determine if the connection is trusted.
-
Device health - Confidence that a device is compliant with configuration policies, and is in a good state i.e. the latest patches have been installed, or a feature like secure boot is enabled.
These are the foundations of zero trust architecture design.
In the zero trust network model it's more important than ever to know your assets.
In a zero trust architecture, identity becomes the new perimeter, it is important to have a single source of identity for each of the following: user (human), service (machine or software process) and device.
The health of devices, user behaviour and services are some of the most important signals used to gain confidence in them.
Every request to access a data or a service should be checked by a central policy engine, which compares signals with access policies to determine an access decision
In a zero trust architecture, we assume the network is hostile and authenticate all connections that access data or services.
Given that devices and services are more exposed to network attack than in traditional architectures it's important that comprehensive monitoring for attacks is carried out.
In zero trust the network is considered hostile, therefore build trust into users, devices and services rather than the network.
Select services with built-in support for zero trust network architectures.