From Castle-And-Moat To Zero Trust: Towards a SASE future

The Internet was created in the 1970s, and few could have predicted the impact it has had on our lives. In just half a century, it has…

Photo by Bernardo Lorena Ponte on Unsplash

From Castle-And-Moat To Zero Trust: Towards a SASE future

The Internet was created in the 1970s, and few could have predicted the impact it has had on our lives. In just half a century, it has changed virtually every aspect of the way we live our lives, and few can avoid it. Without it, we would struggle to run our societies. Our banks, transport networks, media, health care, and governmental infrastructures are all now typically built around the Internet and the public Cloud. Increasingly, too, security, integrity and resilience play a core part of these infrastructures, and in a way that was never really thought about when we created the protocols that run the Internet. The hotch-potch of different protocols, services and data infrastructures has made it increasingly difficult to manage our corporate infrastructures.

And, the creation of the Internet was not a top-down approach to its design — it was very much a bottom-up approach. It all happened through LANs (Local Area Networks), and where we connected to local networks and ran local applications. The administration of services on these separate LANs became difficult, and so we centralised the services onto servers and which served multiple LANs. For this, we need gateways between the LANs. The security of interLAN access was then governed through these gateways.

From LANs to Zero-trust

Once email and Web came along, we decided to then link our LANs to gateways which allowed us to link the LANs, and onto the Internet. If you wanted access to your corporate network, you connected to it over a LAN. The access control was then to allow everyone to connect from a LAN, and then use usernames and passwords to control access to localized services. The corporation then put all the trusted things on one side of a firewall and all the untrusted things to the other side. An enhanced approach put all the semi-trusted services within a DMZ (Demilitarized Zone), and thus limits direct external access to private networks. Organisations then build up their own corporate data and service infrastructure and put them behind firewalls.

But, our world has changed. The Cloud can now replace corporate data and service infrastructure in a less expensive and more robust way, and where most of us now do not even connect directly to our corporate network. The pandemic, too, accelerated the move towards connecting to our networks from any place in the world. It was place all our data and services in the Cloud, which also means that anyone else in the world can also connect to them. This leads us to the principle of zero-trust.

Three generations

When we look back on the creation of the Internet, we will see the Internet being built with three generations [1]:

  • Generation 1 (Castle and Moat): This is a traditional network which has a company-owned data centre or corporate infrastructure behind firewalls. Access happens by granting access to a LAN or WAN through private LANs.
  • Generation 2 (Virtualised Functions): This is where users do not connect directly to the corporate network, and where many of the services are based in the Cloud and where most of the traffic is Internet-bound. This ends up as a patchwork of accesses with some being cloud-based and others running within Generation 1 environments.
  • Generation 3 (Zero Trust). This is a true migration for all the networks and services into the Cloud, and where access to content and services is delivered almost instantly. This type of infrastructure is often defined as SASE — Secure Access Service Edge. As accesses run in the Cloud, there must be zero trust applied, as users can access the services from anywhere.

Migrating with WARP

The Cloudflare One product [1] is one service that aims to support the migration towards the 3rd generation. It uses a lightweight roaming agent (WARP) which connects to any IP-connected device (including user workstations). This then creates encryption tunnels using either GRE, IPsec or CNI. This tunnel links the servers directly to the accessed devices. Users then install the WARP client on their device as a proxy and then will be isolated within a corporate namespace, which will be matched to the customer’s own routing and tunnel configuration.

But there’s an advantage in that this tunnel automatically connects to the nearest Cloudflare connection, allowing for fast access times no matter the physical place of the connection. Along with this, there is resilience in that there are another 1,600 city locations where a user can connect their tunnel to. Traffic returning can then take any one of these city locations as an entry point.

Figure 1: Cloudflare One [here]

Users then install the WARP client on any device to proxy traffic to the closest Cloudflare location. From there, if the device is enrolled with a Cloudflare account with Zero Trust and private routing enabled, its traffic will get delivered to the account’s dedicated, isolated network “namespace”. This namespace — which exists on every server in every Cloudflare data center — holds all the routing and tunnel configurations for a customer’s connected network. It is a bit like our existing VPN networks but running within a Cloud infrastructure. This routing can then involve adding QoS (Quality of Service) to the traffic, such as prioritizing critical corporate services against more trivial ones), or for load balancing.

Anycast

Overall, Anycast is used to simplify routing, and where corporate networks or bundles of servers can be defined with a single IP address. The routing then delivers the content to the nearest place to the target, and which is then picked up there for the specific IP location. When traffic returns from a session, it will be forwarded to the closest Cloudflare location. The Cloudflare servers then share information on active sessions, and where the access server will forward the traffic to the service which is handling the session, and for them to then forward the traffic. This service is known as Hermes.

Conclusions

The future is zero-trust. Overall, the usage of a proxy is one way to migrate towards a zero-trust approach, but the actual building of it requires careful design of system architectures and to design services which run inherently in the Cloud and where data is stored and accessed only from Cloud infrastructures. It is a scary thought for those brought up on the castle-and-moat approaches but is the only way forward for many networked infrastructures as it should vastly improve security, integrity and resilience. The Internet is now too important to us, and we need to make sure we use it properly.

A true Cloud-based infrastructure will connect users directly to the Cloud, and give them access to the services and data they need — also provided directly from the Cloud. Delays and access requirements will — hopefully — all be a thing of the past. We are a long way off in creating these infrastructures, but migration is happening. The old Internet will feel like a Ford T compared to a Tesla car — and where the greatest machine ever created will truly achieve its full potential. Whether we use it to this potential is yet to be seen.

The worries around resilience and the slow access times of the Cloud are now blending into the past — the Cloud is often much faster to access than our corporate networks (especially where we have content placed at the edge of the Cloud), and it is generally more resilient (with truly multiple places to access the same service or data element). The pandemic has accelerated this approach.

Our main worry now is making sure our security works. Encryption, encrypted tunnels and defining trust for every access must play a core part in our future digital world. So, go learn some encryption!

References

[1] https://blog.cloudflare.com/bridge-to-zero-trust/