On October 29, the National Cyber Security Center of the United Kingdom issued a draft of the “Basic Principles of Zero Trust” to provide reference guidance for the migration or implementation of the zero trust network architecture of government and corporate institutions.
The network architecture is changing rapidly, more and more services are being migrated to the cloud, and the use of software as a service (SaaS) is also growing. At the same time, various organizations have begun to adopt increasingly flexible working methods, allowing employees to access business systems through multiple devices in various locations.
Traditional network boundaries are disappearing, and the value of traditional defense solutions is also falling apart. Zero trust is a network architecture that specifically applies such changing conditions. The eight principles outlined in this guide can help you build your own zero-trust network architecture.
The default network environment is malicious in nature
In the zero trust architecture, we no longer have any inherent trust in the network. Therefore, access to the network does not mean that you should or have access to all content on the target network.
During the intrusion, the attacker usually establishes a landing point in the target network, and then realizes lateral movement by relying on the principle of full trust within the network. But in the zero-trust architecture, we assume that the network environment is malicious in nature.
Eliminate the default trusted thinking in the network
To eliminate the default trust thinking in the network, a new trust mechanism must be established for users, devices, and services. The establishment of trust is inseparable from the comprehensive control of the user’s identity (passed identity verification), the operating status of the device and the services (authorization) accessed.
In order to achieve a zero trust mechanism, you should authenticate each connection to the service, and authorize devices, users, and connections according to rules and policies. Regardless of where the connection request comes from, these policies independently evaluate your trust in users and their devices and grant them access to resources accordingly.
To implement authorization decisions, you should clearly define access policies based on who needs to access which service or which data under which conditions.
Your specific level of trust depends on the value of the data you access and the potential impact of the actions you perform. You should take inventory of the equipment and monitor the operating status of the equipment according to the defined policies (such as encryption, patch repair level, etc.).
If you are not sure whether the zero-trust architecture can meet your actual needs, or want to learn more about the zero-trust architecture, our network architecture guide will be helpful to you.
01 Who is this guide for?
This guide is aimed at the following technical audiences: system engineers, solution and security architects, and CISOs. You can also introduce relevant principles into the review framework when performing security assessment or assurance work.
When implementing related designs, you can use these principles as a guide for selecting technical functions.
Organizations or open source projects that implement zero-trust related technologies can also use these principles to guide their own development and evaluate which aspects of the zero-trust architecture are difficult to implement.
Although the use of these principles cannot completely guarantee the security of the architecture, it can at least help you focus on dealing with truly sophisticated and complex problems.
02 Emerging and evolving zero trust architecture
IT systems have been evolving and changing. Based on this, the principles presented here cannot be static and rigid. Remember, zero trust architecture is something that has just emerged and is still evolving.
During the implementation process, you may find that you cannot meet all the principles at once. This may be because your existing technology cannot support zero trust architecture. In fact, this is a fairly common situation, and I am afraid that it will not be fundamentally resolved until the zero-trust technology matures.
Please put practical first, including continuing to support traditional security control mechanisms. As the system gradually transitions to a zero-trust architecture, you will find that you can follow more and more principles.
Your architecture should have sufficient flexibility to adapt to changing needs without affecting the normal user experience. You should consider how to add new services, move between services, and enable/disable various functions. This flexibility will enable your users to use new features at any time, and also ensure that you can quickly respond to new vulnerabilities and threats.
You should review your architecture regularly and make timely changes to improve the availability and security of the system.
03 Implementation of Zero Trust Architecture-Step by Step
The transformation of the existing system architecture cannot be accomplished overnight.
No matter how long the existing network has been used and how many outdated services it contains, you should design a phased implementation method for the deployment of the zero trust model to promote multiple rounds of iteration. It takes time to establish a new architectural foundation. For example, it is often time-consuming to establish strong identities for users and devices, or deploy modern authentication systems in organizations.
When transitioning to a new architecture, especially before implementing and testing a zero-trust control mechanism, please do not rush to deactivate traditional security control methods. Taking into account the powerful control principles of the zero trust architecture, once the system is not properly configured and tested, your business is likely to be directly exposed to risks. For example, before you are sure that your zero-trust architecture can solve all the potential threats handled by the VPN in the past, please do not delete the VPN connection easily.
In addition, the traditional system may still need to be hosted by the traditional network architecture, or it may not be able to support certain features of the zero-trust architecture. Therefore, you may need to manage both traditional network boundaries and zero-trust architecture in certain environments. Specifically, you may need to reserve a separate VPN tunnel for legacy applications or authentication agents. When updating the old system, please try to support the zero trust architecture at the design level.
Even in a new environment built from scratch, the implementation of the zero trust model can be difficult. The products currently on the market often fail to fully satisfy all of the following principles. Therefore, your security architecture also needs to cooperate with sound risk management methods.
When discussing zero trust architecture, everyone should establish a glossary of terms. The following are some of the terms used in the principles of the zero trust architecture. We combine various terms with other sources to accurately describe the zero trust technology.
Access policy-the specification used to manage access requests, including verification of the credibility of the request and authorization behavior.
Configuration strategy-a strategy used to describe configuration options in devices and services.
Signals—including information such as equipment operating status or location, can be used to determine which assets are trustworthy. You often need to use multiple signals to determine the resource access permissions granted.
Signal database-long-term signal storage solution, used to support access decision-making at any time.
Policy engine-the component responsible for receiving signals and comparing them with access policies. The strategy engine usually manifests itself as a third-party product or service that can be purchased from a supplier.
Policy enforcement point-Use the policy engine to direct device requests to the target service to determine whether the connection is trustworthy.
Device operating status-to ensure that the device complies with the configuration policy and is in a good operating state, including the latest patch has been installed, or safe boot and other functions have been enabled.
05 Specific principles
The following eight principles are the basis for the design of the Zero Trust Architecture.
1. Know your architecture, including users, equipment and services
In the zero trust network model, understanding your assets is more important than ever.
2. Know your user, service and device identity
In the zero-trust architecture, identity has become a new boundary. It is very important to have a unique identity source for the following items: users (people), services (machines or software processes), and equipment.
3. Understand the health of your users, equipment and services
The health of the device, user behavior and service are the most important signals for gaining user trust.
4. Use the policy to authorize the request
Each request for access to data or services should be checked by the central policy engine, which compares the request with the access policy to determine the access decision.
5. Always verify
In the zero-trust architecture, we assume that the network is malicious and authenticate all connections to access data or services.
6. Focus on monitoring equipment and services
Given that devices and services are more vulnerable to network attacks than traditional architectures, it is important to monitor attacks comprehensively.
7. Don’t trust any network, including your own network
In zero trust, the network is considered malicious, so trust is built on users, devices, and services, not on the network.
8. Choose a service designed for zero trust
Choose services that natively support zero-trust network architecture.