Security in a perimeterless world…
A practical take on ‘zero trust’ with Google’s BeyondCorp Enterprise
Introduction
“Perimeter Security is Dead”
There, I said it — and I am far from the only person to come to this conclusion (cf. my CTS colleague Jonny O’Connell’s excellent recent blog post about this very topic). Today though I want to pose a few follow-up questions, the first of which is:
What does IT security look like in a world without perimeters?
To answer this, I want to tell a story. In 2010 Google announced that they had suffered from a sophisticated and targeted cyber attack, in what was later termed ‘Operation Aurora’. This breach led to a time of reflection in Google around their security posture and a realization that perimeter defenses weren't adequate at providing the level of information security they required. Recently, Google even published a really interesting video series under the ‘Hacking Google’ title, with the first video being about this major hack:
Over the subsequent years, they then went about building and refining their security defenses based on zero trust principles, the result is this whitepaper which was later productised into BeyondCorp Enterprise which I am going to cover later on in this post.
First, though I want to pose a question…
How do you securely deliver business applications to end users?
In many traditional organisations in ‘pre-covid’ times, this was fairly straightforward — your users would work from one of your offices where they would connect to your trusted network. Applications may well have been served from your own data centres (sometimes even in the same building), connected to this network. If you had branch offices you tended to extend your network with technologies such as MPLS to enable applications to be delivered there — home & mobile workers would then connect to your network using Virtual Private Networks (VPNs). So what has changed? Well a couple of things; firstly, application delivery is now largely cloud-based, whether it be SaaS, PaaS, or IaaS; secondly, an increasing amount of your organisations employees are working remotely. We have been seeing the effect of this for a while; well before covid, I rolled out Office 365 in two separate organisations — and what did we see? A massive drop in VPN usage as many individuals no longer needed to be connected to our network in order to effectively do their jobs. We also saw a (not surprising) increase in traffic breaking out of our network to the wider internet. Net result:
Individuals no longer needed to be connected to our network in order to effectively do their jobs
With cloud-based SaaS applications such as Google’s Workspace, Office 365, Salesforce, ServiceNow, and GitHub (.com) to name but a few, the primary security control in place is identity rather than network connectivity, with organisations often integrating into their existing active directory (or other IdP such as Okta) via syncing (Google or Microsoft), and SAML or OAuth-based SSO with these services — ideally with MFA to reduce the risk of identity compromise.
Further to the above, you are also seeing an increasing number of internal browser-based applications being protected by some sort of identity-based access. The two main examples which stick out to me are Microsoft’s ADFS + WAP combination and Azure AD Application Proxy or Google’s Identity Aware Proxy (IAP). This is hardly new tech either - I was using ADFS and WAP to provide remote access to an on-premise Sharepoint farm 5 years ago.
Something that has definitely changed in the last 5 years is where applications are being hosted. Many organisations are increasingly using SaaS, IaaS, and PaaS services across multiple clouds. When this multi-platform hosting is then combined with an increasingly WFH and mobile workforce you end up with an application delivery strategy that ‘ideally’ resembles a point-to-point rather than hub and spoke model.
I say ‘ideally’ as I have also seen organisations serving applications through the hub of their network which frankly is causing increased latency and bandwidth requirements on company circuits such as MPLS.
So what do I think is the answer to solve these problems of an increasingly distributed workforce, working on a multitude of different devices whilst maintaining the application performance they have come to expect? Well, BeyondCorp Enterprise…
BeyondCorp Enterprise
As I mentioned earlier BeyondCorp Enterprise is one result of Google’s response to the Aurora hack I mentioned above. Fundamentally BeyondCorp Enterprise is a productised version of some of what Google does to protect itself. You can, therefore, rest assured that this solution has been stress tested by many of Google’s 140,000 employees.
Fundamentally BeyondCorp Enterprise allows you to protect and control access to your cloud based apps in a similar fashion to Google — using both Google’s infrastructure and security approach.
What Google found was that simply relying on the network to provide security wasn’t good enough and that once a single system was compromised attackers were able to move horizontally across their platform. Google came to the simple conclusion that the network couldn’t and more importantly shouldn’t be trusted, ‘zero trust’ if you will.
So time for another question…
What do you trust, and how do you establish that trust?
I would like to pose that identity is something you can trust, identity can be verified using multiple MFA methods (mine and Google’s preferred method being hardware keys). You should have a reasonable idea of where a user is logging in from and what hours they are likely to be working. If they have subcontracted their job to China and spend their day surfing the web I should know about that. This all sits under what Google and others call context-aware access and more specifically user context access.
In addition to user context, Google is also able to offer device context where the Chrome browser is used. This allows you to only grant access to users logging in from devices that have certain OS versions or patch levels, specific certificates installed, or are disk encrypted for example.
Anyway — time for another question…
How can BeyondCorp Enterprise serve my applications?
To give the ‘consultant answer’, it depends on where your application is hosted and what technology is in use. If your application is hosted in Google Cloud and served over HTTP(s) that is just the case of enabling IAP for your given service with slight differentiation depending on if your service is served using App Engine (GAE), Compute Engine (GCE) or Kubernetes Engine (GKE). You can also secure the administrative interfaces (eg SSH or RDP) of a Virtual Machine using IAP TCP port forwarding.
But what if your applications aren’t hosted in Google Cloud? Well, BeyondCorp Enterprise is just as effective with a touch more configuration using either the app connector or the on-prem access connector let’s look at each of these in more detail starting with the app connector.
The app connector works by deploying a remote agent in an environment with access to HTTP(s) application. This then establishes a reverse TLS encrypted tunnel to a Google-hosted App Connector Gateway. This gateway is then accessed by using a Private Service Connect (PSC), Network Endpoint Group (NEG) backend on an HTTP load balancer with IAP protecting it. This solution works really nicely if you don’t have any other form of hybrid connectivity into the environment your application is hosted in which brings us round nicely to the on-prem access connector.
In this model a hybrid connection is first established, an interconnect is shown in the HLD but a VPN would be sufficient depending on traffic and latency requirements. The connecter itself then effectively acts as a forwarder between the load balancer (with IAP) and the application hosted at the other end of the hybrid connection. This method does of course require the hybrid connection to exist and for DNS resolution and network connectivity to already be established but it could be quite fast to set up assuming these were already in place.
Anyway time for yet another question…
So that covers HTTP(s) applications but what about my other applications?
For non-HTTP(s) applications Google has the BeyondCorp Enterprise client connector.
This works by using an agent installed on the client machine (Windows and OSX clients available) that works with endpoint verification in Chrome to establish sessions with a Google-hosted client connector service. This then routes traffic out to the application using existing VPC-based connectivity to applications hosted in Google Cloud or elsewhere. In some ways, this is similar to the TCP tunneling you can use with IAP into Google virtual machines but goes further in providing access to a broader suite of applications.
If you want to play with some of the technologies involved here there is actually a Google Cloud Skills Boost Quest based on BeyondCorp Enterprise.
I wanted to finish up this section by posing a final question which is…
What does the future look like for BeyondCorp Enterprise?
At the beginning of December Google and Palo Alto announced a tighter partnership with deeper integration between BCE and Palo Alto’s Prima Access product. The detail surrounding this is still a little light but I think the combination of Google’s network and scale and Palo Alto’s experience should lead to some compelling developments going forwards.
Conclusion
So, in this post, I have tried to detail why I think traditional perimeter security is dead, and why I believe identity to be the key trust mechanism for the future. I have talked about Google’s primary solution in the space of ‘Zero Trust’ — BeyondCorp Enterprise — and how this is practically implemented at a technical level. Until next time — keep it Googley :)
