Network architecture is changing. More services are moving to the cloud, there is a surge in the use of Software as a Service (SaaS), and users are embracing flexible working on multiple devices in a variety of locations. The traditional network perimeter is disappearing and with it, the value of traditional defences.
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. This is commonly seen in breaches; an attacker gains a foothold in a network and is able to move laterally because everything on the network is trusted. In a zero trust architecture, the network is treated as hostile.
However, in order to remove trust from the network, you need to instead gain confidence in the authentication, verification and authorization of users and services. This is achieved by building trust into the user's identity (user authentication), their devices (device verification), and the services they access (service authorisation). For this model to be effective, each connection to a service should be authenticated and the device and connection authorised against a policy, regardless of where the connection request comes from.
To enable authorisation decisions, access policies need to be defined, based on who can access which service or data, under which circumstances. How much confidence you need to trust a connection depends on the value of data being accessed or impact of action being performed. Likewise, devices should be inventoried and device verification should be based on defined policies (such as encryption, patch levels, etc).
What does this guidance do?
These principles are intended to help you design and deploy a secure end-to-end, zero trust architecture. This will stretch from your users and their devices, through to the services and data they are accessing. You'll also get a clear understanding of the zero trust model, the benefits it brings and the risks you'll need to consider.
These principles are also not intended as a list of compliance standards. Consider all the principles and develop a plan on how you can implement them on your journey to a zero trust architecture.
Who is this guidance for?
This guidance is aimed at a technical audience such as 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.
Terminology
When discussing zero trust architectures it’s useful to have a common language. Below are some terms used throughout our principles. We’ve tried to closely align these terms with other publications to help when comparing between different flavours of zero trust architecture.
Access Policy – Policies that determine the required context of a request for it to be considered trusted and authorised.
Configuration Policy – Policies that describe configuration options for devices and services.
Signal – A piece of information used to gain confidence that you can trust an asset.
Signal database - A long term store of signals used to make access decision and for analysis.
Policy Engine – The component that takes signals and compares them with access policies to determine an access decision.
Policy Enforcement Point – Mediates requests from a device to a service using the Policy Decision Engine to determine if the connection is trusted.
Stay nimble
IT systems rarely stand still, they change over time, these principles are not intended to be applied once and be forgotten. This is especially important for a zero trust architectures as they are relatively new and still evolving. They should be used throughout the lifecycle of your system.
Your architecture needs to be flexible enough to evolve, meeting changing needs, without impacting users. Consider how you would add new services, move between services, enabling and disabling 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.
Your organisation, technologies and good practice will change over time. Re-visit your architecture periodically and implement any changes that improve the usability and security of your system.
Take your time
An existing system’s architecture can’t usually be completely changed 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 foundations required 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 you may leave your systems exposed and at considerable risk if they aren't properly configured and tested.
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.
The principles
We then dive into the ten principles. These are the foundation of designing a zero trust architecture.
Know your architecture including users, devices, and services
In the zero trust network model it’s more important than ever to know about your assets. In order to get the benefits from zero trust you need to know about each component of your architecture from users and their devices, through to the services and data they are accessing.
Your attention should be focused on the components of the system which use the network. The network itself should be considered untrusted and hostile, regardless of whether it’s a local networking in your secure building, or a public Wi-Fi network in a known hostile location.
This principle is particularly important if transitioning to a zero trust architecture for an established system, with many pre-existing services. If a zero trust architecture is implemented without considering existing services, they may be at higher risk as the network is assumed to be untrusted and hostile. These services may not be designed for this situation and therefore will be unable to defend themselves against attack.
Create a single strong user identity
Your organisation should use a single user directory and create accounts that are linked to individuals.
To enable granular access control, create specific roles for each user. Ensure the directory can be employed by all the services you plan to use, both internal and external. This will also help when accessing other organisation's services and data.
Desirable features of an identity service include:
Create groups
Define roles
Support for strong, modern authentication methods such as multi-factor authentication or even passwordless authentication
Easily, but securely, distribute credentials to users
Authenticate to external services (e.g. SAML 2.0 or OpenID Connect)
Manage user identities in external services (e.g. SCIM 2.0)
Support for your joiners, movers, and leavers processes
If you have an existing directory, migrating to another directory will require careful planning. Some directory services allow you to import, synchronise or federate between directories, this would allow a phased approach to migration from your legacy directory service to one which supports a zero trust architecture.
Service accounts, keys, tokens and so on, should also be created in a central directory, with tightly defined permissions which are the minimum necessary to allow the service to function properly.
You should also consider how you’ll offer access to the resources your organisation controls, to people from outside your organisation. Your services should be able to use external identity providers to allow access to appropriate services and data. For example, a visitor can see the lunch menu, or a contractor can only access documents related to their work.
Identity is a wide-ranging topic and needs careful consideration as it's a foundational service for zero trust architectures. The NCSC has more in-depth guidance on identity and access management. https://www.ncsc.gov.uk/guidance/introduction-identity-and-access-management
Each device owned by your organisation should be uniquely identifiable in a single device directory. This enables efficient asset management and clear visibility of the devices which access services and your data.
Policies you define later will use compliance and health claims from a device to make decisions about which data it can access and the actions it can perform. A strong identity is required to ensure these claims can be authenticated.
The confidence you can have in a device’s identity depends on the device type, hardware and platform:
Identity stored on a secure hardware co-processor, like a TPM, will give you high confidence in the device’s identity
Identity stored on a well-managed device using a software-based key store gives a lower confidence in the device’s identity
Identity on an unmanaged device in a software-based key store gives a low confidence in the device’s identity
When allowing requests from devices you don’t own and manage, identification can be challenging. Devices in a BYOD model should still have an identity linked to them but the confidence in that device’s identity may be lower.
Identifying devices from another organisation will require a trust relationship to be established between the two organisations. This should happen at both a governance and technical level.
Services may be available directly over the internet, so authentication of user requests requires a stronger mechanism than a simple username and password combination.
Multi-factor authentication is a requirement for a zero trust architecture. This doesn’t mean that the user experience has to be poor. On modern devices and platforms, strong multi-factor authentication can be achieved with a good user experience.
Consider adding additional factors depending on the impact of the request,like using tokens or one-time passwords, device type and state, physical location and user behaviour analytics.
It’s important that strong authentication doesn’t hinder the usability of a service. So, only prompt for additional authentication factors when requests are of high impact or importance. For example, when accessing sensitive data or requesting privileged actions, such as creating users.
Passwordless authentication (e.g. FIDO2) is an ideal solution which provides strong security with an excellent user experience. Consider implementing passwordless authentication for a strong, consistent, and simple authentication experience across all of your services.
Requests between services also need to be authenticated. This is normally achieved using API tokens, frameworks such as OAuth or Public Key Infrastructure (PKI). Use mutual authentication wherever possible.
Devices
Determining if the device accessing your services is up-to-date, compliant with your device configuration policies and in a healthy state is important as these represent some of the most important signals used to control access to services and data.
First, define policies which configure devices to be secure, NCSC’s end-user device guidance can help. Using a device management service, apply these policies to devices and enforce them, then continuously check that devices are compliant.
Device health consists of compliance with device configuration and device state. Is the device compliant with the policies that you set? Is the device in the expected state?
Device state can be determined based on the state of security features on the platform. For example, is secure boot enabled? Are the latest operating system updates installed? Is virtualisation-based security or system integrity protection enabled?
Going further, determining the underlaying state of a devices’ firmware, BIOS, and operating system kernel are strong signals which contributes to determining its overall health. Attestation is a way of achieving this, taking a snapshot of the state of a device with claims about different components of the hardware and operating system, that are reported to the signal database for analysis.
Systems that implement attestation to gain confidence in initial device state, may include subsequent cryptographic checks of launched applications and services to extend the breadth of health measurements regarded as strong signals.
Services
The health of services should also be considered, not only when end-user devices are accessing services but also when services are talking to other services. The supporting zero trust infrastructure, such as the policy engine and policy enforcement points should also be considered services when reading this principle.
Services should be configured to use their native security functions as per documentation and to satisfy the principles of zero trust. For instance, enforcing strong authentication mechanisms and disabling legacy protocol that don't support modern authentication.
Services also need to be kept up-to-date with the latest software patches and you need to be able to determine the version and patch level of the service you are using. Patches fixing vulnerabilities should applied at the earliest opportunity.
The health of your services needs to be monitored, an unexpected change in state may indicate an unauthorised change or malicious activity. How this is achieved will depend on the type of service, ideally this would be carried out programmatically by interrogating an API that the service provides.
Focus on device and service monitoring; what are devices requesting from services, what actions are they performing, what data are they accessing. Your monitoring should link back to the policies that you set, verifying they are being enforced as you expect.
User devices within a traditional walled garden network architecture use a VPN to send all traffic through a controlled path, which enables traffic to be inspected. In a zero trust architecture, this chokepoint isn’t available and protective monitoring has to be moved onto each device.
Although the network is untrusted and assumed hostile, network monitoring is still important to ensure good performance and good cyber hygiene. Network monitoring should be carried out on your local networks to identify rogue devices and help identify malicious activity, especially if you’re hosting on-premise services. Coupled with device monitoring, network monitoring can help improve visibility and correlation; for example, you could trace network connections to the process on the device that generated them.
In the previous principles we talked about building trust in a user’s identity, their devices and services. Signals from these sources can be used to make access decisions. For example, has a user authenticated using a second factor? Is the device they are using compliant with our configuration policies?
Define your policies based on the value of the data to be accessed or action taken. For example, a high impact action, such as creating a new administrator user, should require a stringent policy compared to a relatively low impact operation such as checking the lunch menu. In the latter example, the confidence required to trust the connection is relatively low.
Signals can include the user’s role, physical location, device state, value of the service they are accessing and risk of the action they are preforming. The richness of the policies you define is determined by the policy engine you are using and is closely linked to the user and device state signals available. When choosing which technologies to use for your zero trust architecture, evaluate the signals that are available and capabilities of your policy engine.
Depending on your policy engine's capabilities, you may be able to request additional signals in order to get more confidence in a connection. For example, if a user usually requests access to a high value service for the first time or outside of normal working hours your policy engine could ask for an additional factor of authentication.
A zero trust architecture includes a component which mediates connections to services. This is a Policy Enforcement Point which actively applies the access policy you have defined based on a response from the Policy Engine.
How this is achieved practically depends on the zero trust supporting infrastructure you use and the flavour of zero trust technologies you deploy.
If using software defined perimeter (SDP), the policy enforcement point is usually the SDP controller that controls connections from a central location which may also be the Policy Engine. Enforcement points will focus on properties of the network connection to control access, for example which network protocols can be used, the origin of the connection, the network segments that can communicate based on the policy.
When using micro-segementation there is often a gateway in the form of a reverse proxy component. This component can enforce policy at many layers, from the network layer through to the application layer. At the application layer the gateway would need to understand the protocols being used by the application and how they are used. This may require complex logic in both the policy engine and the enforcement point.
Often in a cloud environment you may control access using an authentication and authorisation broker which provides single sign-on functionality to variety of applications. Enforcement is usually session based, policies will be assessed as a connection is established and the broker provides a short lived access token which allows users connect to the services they originally requested.
You may use a combination of the options above, or even different ways, to control access to your services and data. Regardless of how you design your zero trust architecture the component should only allow connections if the access policies you define are satisfied. As monitoring is important in a zero trust architecture your enforcement point should support logging connections and their properties.
Other considerations
When an access decision is denied consider how the user will be informed about the reasons why. Too much information may facilitate an attacker, too little may frustrate a legitimate user.
Should an emergency arise where access to data is critical, you may need to have a process in place which allows a connection to be established even if an access policy can't be satisfied. In such a scenario the risk needs to be managed carefully to prevent this feature being abused. For example, limit the risk of emergency access by allowing an individual user account, a specific device, from a specific location, for a limited time.
Prefer services with built-in support for zero trust.
Some services, especially legacy services, may need additional components to enable zero trust. This may increase management overhead and cause usability issues, so ensure you have the resource to take this on.
Creating your own supporting infrastructure should be avoided, due to the cost, complexity and potential for error involved. In this case, as elsewhere, the general cyber security principle of “don’t roll your own” holds true.
Given that in a zero trust architecture, you can’t trust the network, services need to be designed to protect themselves from hostile networks. This includes the internet, to which components could be directly exposed.
Whenever possible, use standards-based technologies. This allows interoperability between devices and services. A good example is authentication, where common standards such as OpenID Connect or SAML allow you to use a single directory service to authenticate to many services.
Unfortunately, there are currently no standards for policies. We recommend that you use a single policy engine and apply the full set of features it offers.
📁 Files – features an improved sidebar, accepting internal shares & folder owner transfership
🗃 Workspaces brings context to your folders, facilitating collaboration in one place.
🔏 File locking prevents conflicts editing shared files with others
🤖 Flow – Brings extensive, easy to use workflow capabilities to Nextcloud. Automatically turn documents in PDFs, send messages to chat rooms and more!
📝 ONLYOFFICE – Built in ONLYOFFICE makes collaborative editing of Microsoft Office documents accessible to everyone
📸 Photos – A brand new image gallery makes finding, browsing and sharing your images easier than ever before.
📅 Calendar 2.0 – Calendar 2.0 books Talk meetings, brings busy view for meetings and resource booking and more
📩 Mail – Mail 1.0 recognizes itineraries, handles rich text mails and more
🗣 Talk – rewritten user interface brings message delivery notifications, circles support, message replies and flow integration
$100.00 /month
$34.99 /month
$19.99 /month (office without email)
Zero trust architecture design principles
Ten principles to help you design and deploy a zero trust architecture.
Nextcloud Hub
Save 70% Replacing G Suite, Basecamp, Office 365
Gsuite, Basecamp or O365
Private Cloud Office BA.net
BA.net/office
+54911 2546 1403
iphone@ba.net
BA.net - Private Cloud Office Hosting Replace O365 Managed Nextcloud Onlyoffice MS Microsoft Office Compatible Word Document Sharepoint Spreadsheet Excel Power Point Presentation Self-Hosted Premises Collaboration Groupware Talk Chat Teleworkers Remote Teams Office 365 G suite Gsuite Basecamp Slack Alternative back office gdpr cipa affordable easy enterprise files backup restore cloud storage server msp isp iphone@ba.net
About BA.net