Beyond the Patch

BeyondCorp

I want to take the wind out of the sails of an argument often raised against the BeyondCorp principle right from the start: Google's solution does not mean that admins completely dispense with security precautions. Quite the opposite: The servers that Google operates for services like Gmail or Google Drive are subject to explicit, very strict, and tightly meshed rules. The point is far more that Google does not differentiate between "internal" and "external" connections for its own services. Instead, every client is basically considered untrustworthy.

Therefore, an individual client does not automatically receive more rights than others simply because it has a certain network address or is located at a certain physical location (Figure 3). Rather, any employee can access their resources from any client in the world at any time, as long as the client with which this happens adheres to a few rules that make it trustworthy, and it is those rules that make up the BeyondCorp principle.

Figure 3: In BeyondCorp environments, clients are granted access only if they can identify themselves as authorized on the basis of multiple factors. Here, the app is asking if I am trying to log in and whether I have tried logging in near Berlin, Germany, on my Intel Mac OS X 10.15 device.

Incidentally, Google's approach has inspired a number of other tech giants. Netflix also says that it now uses a zero trust architecture (i.e., a system in which the provider's services do not trust a client at all, regardless of where it is). Netflix calls the principle location-independent security approach (LISA) and has admittedly invented a far nicer name than Google. BeyondCorp, LISA, and most zero trust approaches use the same basic principles; therefore, in the further course of this article, I will no longer distinguish between the implementations.

What BeyondCorp Is All About

BeyondCorp's central approach is to approve access to any service only if it meets several requirements. It must always be authenticated; that is, the requesting client must have proven that it is authorized for the requested resource. High standards apply. Additionally, access must be authorized. A central rights management system must therefore specify that the client is allowed access to the resource it is currently trying to access.

Encryption of the connection is mandatory, not optional. At least this point is taken for granted from today's perspective; however, if you go back 10 years, you could still find some web stores that did not have SSL certificates to process orders securely. Google's BeyondCorp concept would not, of course, allow connections without encryption, because that would mean that any bad guy with access to the line between client and server – often several thousand kilometers in length – could read the data traffic. For a client to be trusted from the service's point of view, it has to be able to use encrypted connections.

However, the requirements for the client and its user are not yet complete. In the context of a BeyondCorp procedure, a user is only granted access to a resource if it is possible to establish a direct connection between them, their environment, and the technical client. What is stated in the BeyondCorp guidelines in somewhat cryptic terms generally means two-factor authentication (2FA) in everyday life.

In this way, Google consequently eliminates the eternal password problem: If 2FA is activated for access, it is initially irrelevant if a user's username and password fall into the hands of attackers. For them to log in and access the client's data, they need the second factor – usually a smartphone – with a suitable app that can be used to grant approval for the respective access. Authentication with an SMS text code has rightly fallen into disrepute today, and applications such as Google's Authenticator offer better alternatives.

For its own services, Google now goes so far as to display a warning in the respective apps (e.g., Gmail) if the same account logs in on another device. If the user does not confirm this access on their own smartphone, Google rejects it. As a rule, smartphones are also secured against access by strangers – for example, by an unlock pattern or facial recognition, which is practically a third factor. Even if the bad guys were to get their hands on the smartphone in addition to the combination of username and password, they would still not be able to do anything with the stolen device.

Strict Regime for Clients

A large portion of endpoint security products only begin to make some form of sense in the context of BeyondCorp. After all, only if a service can make decisions about allowing or denying the connection on the basis of various properties and parameters of the endpoint in question does the admin gain genuine control over the individual clients, which admittedly requires a bit more than just properly configured services.

For good reason, mobile device management is a fixed component of all LISA and BeyondCorp environments. If a smartphone is lost, the respective owner (e.g., the company) can remotely delete the device and render it unusable, making BYOD scenarios possible: Anyone who wants to use their own iPad can do so if they place the device under the auspices of the relevant compliance and security team. As a rule, this condition does not restrict the functions, but the user does relinquish some of their sovereignty over the device.