Traditional VPN v.s. Zero Trust Architecture
Introduction
To gain access to enterprise resources, the traditional solution architecture is use VPN. For today’s cloud services, there is also zero trust architecture.
If you have on-premises resources, using a traditional VPN-based remote access architecture is one way of balancing remote usability with the risk of compromise.
If you have few or no on-premises services, the VPN may not required, the zero trust architecture can be very effective.
If you are designing a new network, consider following the zero trust network approach instead. The traditional architecture still makes sense where there is a considerable on-premises deployment and/or legacy services to use. However, a zero trust approach will likely be better for organizations predominantly consuming cloud services.
Traditional VPN Architecture
Virtual Private Networks (VPNs) allow organizations to provide secure connectivity between devices in physically separate locations.
VPNs are encrypted network connections. These allow remote users to securely access an organization’s services. VPNs are one way to guarantee the security of ‘data in transit’ across an untrusted network.
VPN advantages
- Enabling legacy systems to work remotely
- Providing a second layer of defence against misconfigured, un-patched, or poorly designed internal services
- Protecting internal network servers from external, unauthenticated attackers
- Protecting user devices from network attacks by preventing direct connections to and from the local network
- Forcing traffic between a device and external services through internal, protective monitoring tools
- Enabling business monitoring and/or filtering of users’ network traffic
VPN high level key components
- The access layer, authenticating remote devices. Network traffic from remote devices is trapped here unless it can subsequently authenticate to local services
- The presentation layer, brokering access to internal services based on corporate policy
- A core network, comprising of on-premise services An internet gateway, providing proxy access to remote websites and enterprise cloud services
Zero Trust Architecture
A zero trust architecture is an approach to system design where inherent trust in the network is removed. Instead, the network is assumed hostile and each access request is verified, based on an access policy.
Confidence in the trustworthiness of a request is achieved by building context, which in turn relies upon strong authentication, authorization, device health, and value of the data being accessed.
Zero Trust Key concepts
The network is hostile
The network should be treated as compromised and therefore hostile, This means you need to remove trust from the network.
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. Each request to access data or a service should be authenticated and authorised against an access policy. If a connection does not satisfy the access policy, the connection is dropped.
It is common in breaches to see an attacker gain a foothold on a network and then move laterally. This is possible because everything and everyone already on the network is trusted with access to the rest of the network. In a zero trust architecture, the network is treated as hostile, so every request for data or service access is continually verified against an access policy. This will also improve monitoring and detection of attempts at lateral movement by an attacker, compared to a traditional wall garden, but zero trust won’t completely remove the threat.
Gain confidence dynamically
If you remove trust from the network, you must instead gain confidence in your users, devices, and services. Rather than taking a snapshot as the user, device or service connects to your network and allowing the resulting permission to persist, you should look to continuously evaluate the trustworthiness of those connections.
For users accessing services, you must build trust in user identity and behavior and device health before they can access the service. For services interacting with each other, such as data exchange using an API, this is achieved by ensuring the right services are communicating with each other and gaining trust in the health of the services your hosting.
How much confidence you need in order to trust a connection depends on the value of data being accessed, or the impact of the action being requested.
For example, accessing sensitive personal data could require an access policy which specifies a list of authorized users with strong authentication, on a device which belongs to the organization and is in a healthy state, based on defined configuration policies such as encryption, patch levels and secure boot being enabled.
On the other hand, accessing low value data, such the lunch menu, may be done by anyone in the organization, regardless of their strength of authentication or device health.
Zero Trust Terminology
When discussing zero trust architectures, it’s useful to have a common vocabulary. Below are some terms used throughout the zero trust principles. We’ve tried to closely align these terms with other sources, to help when discussing zero trust technologies.
Access Policy - The requirements for an access request to be trusted and authorized.
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 in the trustworthiness of an asset. You will often use a number of signals to make a decision whether to grant access to a resource.
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 user or a device to a service or data using the Policy Engine to determine if the requests can be authorized.
Device health - Confidence that a device is compliant with configuration policies, and is in a good state. For example, the latest patches have been installed, or a feature like secure boot is enabled.
A zero trust architecture removes the inherent trust from the network while building confidence in each request. This is achieved through building context through strong authentication, authorization, device health, and value of the data being accessed.
Each connection is strongly authenticated and checked against permissible policies, with the connection being dropped if it is not explicitly allowed.
This approach has many advantages if adopted correctly, but also presents additional risk if mistakes are made.
Whilst the architectural components look much simpler in a zero trust network approach, it is still important to implement authentication and encryption mechanisms to the same or to a greater standard. It also becomes more important to have a strong device configuration, as the device is exposed to a larger set of risks.
How to set up a zero trust network
- Zero trust networking is relatively new and best practices are likely to evolve over time. It’s important to regularly revisit your approach to ensure that you’re taking advantage of the latest features and your policies are still effective.
- Your enterprise applications are now exposed beyond your perimeter. Each one of your internet-accessible services needs to be hardened against attack.
- Implement strong user authentication, requiring multi-factor authentication for every exposed service, including management services. Consider using password-less authentication to mitigate attacks on your users’ passwords.
- Implement machine authentication, with credentials rooted in hardware, taking into account compliance and health attestation, if possible. Monitor logs from authentication services and enterprise applications.
Where a full zero trust network approach cannot be adopted, implement the traditional remote access architecture and as many zero trust networking recommendations as possible.