Leveraging Zero Trust Technologies

What is Zero Trust?

Today’s cloud environments are generally predicated on the use of public, or rather, untrusted networks. In such untrusted networks, the application of security models that have been used in traditional perimeter networks just doesn’t fit. Traditional on-premise networks have, for a long time, been based on perimeter-based security; where access outside “the perimeter” is only granted to trusted devices such as a corporate-issued device that has been hardened, installed with endpoint protections like anti-malware and has access allowed only via a Virtual Private Network (VPN). Essentially, these are devices that adhere to pre-defined organizational policies and enforcements. Much has changed if you think about it. More and more organizations have had to deal with Bring Your Own Device (BYOD) where you have people using mobile devices, tablets, laptops, or any kind of device that doesn’t subscribe to pre-defined organizational policies. Also, those devices have applications that should not be trusted either.

Assume Breach Mentality

Furthermore, these applications and devices commonly reside in untrusted networks such as home networks and can access services in the cloud, which also reside on untrusted networks. In untrusted networks with untrusted applications and devices, using protections such as VPN access and anti-malware tools is a step towards security, but it’s not trusted security. It’s impractical to impose strong policies and enforcements on personal applications and devices that can be used in all manner of ways, such as; browsing insecure websites, parents having their children use the devices for school assignments, playing games, etc. Such activities may likely breach the security installed on that application or device that is deemed trusted. It is safe to assume that such applications, devices, and their users are already compromised.

In such kind of network environments, the best way to protect your cloud services, as we shall see, is to begin by trusting nothing. That is, by assuming every application and device in your network is compromised and further putting mechanisms in your network to get an assurance of what can be trusted and what isn’t. That is the general idea about Zero Trust.

How to Develop Trust

Fundamentally, a Zero Trust network has all manner of users, applications, and devices that are deemed compromised. In that case, how do you develop trust? Trust can be achieved by making use of a control plane for all your users, applications, and devices. The control plane will determine if the users, applications, devices, and cloud services can interact with each other and exchange data.

The control plane should be able to:

1. Sufficiently identify users, applications, and devices – The control plane will reference a trusted identity source. In most cases, that would be a trusted Single Sign-On (SSO) or identity provider. The control plane will further verify the identities using strong authentication, i.e. use of multifactor authentication (MFA), mutual authentication using SSL certificates from a trusted certificate authority (CA) or Token-Based authentication.
2. Define and impose policies – The control plane contains rules that determine if and how the users, applications, and devices can interact with each other and exchange data based on attributes like their email address, asset tags, e.t.c.
3. Variable Trust – The control plane can score the users’ level of trust, applications, and devices based on their attributes and behavior over time.

Implementing Zero Trust

There are technologies that are well suited for implementing Zero Trust architectures. Such technologies and security concepts will be discussed in the section below.

Zero Trust Using Identity-Aware Proxies

Identity-Aware proxies keep getting adopted as a means to achieve Zero Trust and as an alternative to traditional VPN. Ideally, for a user, application, or device to connect to a set of protected cloud services, they have to access the cloud services via the Identity-Aware Proxy. Cloud vendors like Cloudflare, Google Cloud, and Azure already have such a feature.

Most Identity-Aware proxies are normally a mashup of the following: 

1. Identity Providers – Users, applications, and devices’ identities are looked up from a trusted identity source.
2. Asset Inventory – The inventory is used to store the users’ records, applications, and devices that need protection. In most cases, pre-existing technologies such as a DNS, etcd, Active Directory, or typical databases are used to keep the inventory.
3. Data Plane – This is the actual proxy that allows data exchanges and specific communication protocols e.g. HTTP(s) or SSH tunnels that are used to communicate to the protected assets in the cloud.
4. Control Plane – The control plane refers to functions and processes that determine the nature of communication flow between two or more users, applications, and devices based on defined policies and rules.
5. Management Plane – This is normally a web-based or command-based console that interfaces the control-plane using an API. This is where all configurations are done.

Identity-Aware proxies are a good way to implement Zero Trust as they fall in line with the philosophy of sufficiently identifying users, applications, and devices and imposing policies before access is allowed to a set of protected assets.

Zero Trust Using Network Segmentation

Network segmentation helps reinforce Zero Trust by denying access to a set of assets that desire to be protected in untrusted networks. The use of network segmentation in the cloud is naturally a complement to the use of Identity-Aware Proxies as it ensures that access is only allowed by a user, application, or device that has its identity vetted by the Identity-Aware proxy or similar policy-based engine.

Zero Trust Using Multi-Factor Authentication (MFA)

It’s one thing to authenticate a user once, and it’s another to verify how authentic their identity is. Generally, the authenticity of the identity is usually verified by observing different attributes that help affirm the identity of the user, application, or device. Such attributes could be:

1. What a user knows – A secret that only the user knows, like a Password.
2. What a user has/owns – Something that a user always uses like their Mobile Phone or the actual Mobile phone number they can identify with.
3. What a user is – Physical attributes such as their Fingerprint or Facial characteristics.

MFA can also be coupled with constraints such as time and location which help affirm the legitimacy of the identity.

Zero Trust Using Mutual Authentication with a Trusted Certificate Authority (CA)

It’s hard to separate Public Key Infrastructure (PKI) from the concept of Zero Trust. The reason being, PKI has for a long time been designed and associated with ensuring there is trusted communication between different subjects/network components. Aside from the other concepts and technologies described above, using PKI is indeed a bonus in ensuring communication between various applications and devices is trusted. PKI can be used to verify the authenticity of users, applications, and devices.

More so, the use of private PKI with mutual authentication is ideal. Using a private PKI setup gives you control of what can be trusted. Unlike private PKI setups, public PKI reduces the level of trust since you have to rely on a third-party to issue certificates to different parties; that is, users, applications, and devices. You may not entirely be sure about the integrity of the Certificate Authority (CA). Mutual authentication requires two subjects (users or applications or devices) to establish trust before exchanging data/communications.

Protecting ClusterControl in Untrusted Networks

It is recommended to place ClusterControl on private networks, that is, behind a firewall. If you have to place ClusterControl on untrusted networks such as the public cloud, you can use Zero Trust technologies to secure it. 

ClusterControl exposes some modules that are good candidates for integrating Zero Trust technologies. Usually, users can directly access the ClusterControl CLI and Cluster Control Web UI, as shown above. The direct access can be secured by simply placing ClusterControl CLI and Cluster Control Web UI behind an Identity-Aware Proxy as shown in the diagram below. That way, you get to ensure only trusted users can access those administrative modules.

Final Thoughts

As more and more businesses adopt the public cloud, they need to rethink how they can secure assets in that space. Adopting the Zero Trust philosophy helps rethink how you can secure servers such as ClusterControl in an untrusted network.