Google reveals its shift to an open security architecture

Perimeter fences down, security posture up - Google shows how it's done

Google has revealed how it completely changed its security architecture, shifting from a traditional infrastructure to a more open model in which all network traffic is treated with suspicion.

The project, called BeyondCorp, shifted the company from a perimeter security model to one where access to services and tools are not gated according to a user's physical location or their originating network, but instead deploys access policies based on information about a device, its state and associated user.

The model is similar to the approach being pursued by the Met Office, which analyses traffic and responds accordingly, rather than shutting out users based upon rigid policies implemented at the firewall.

The architecture was disclosed in a detailed article published on Usenix. "BeyondCorp considers both internal networks and external networks to be completely untrusted, and gates access to applications by dynamically asserting and enforcing levels, or 'tiers', of access," claim the Google engineers behind BeyondCorp.

Access requirements are organised into "trust tiers" representing levels of sensitivity and resources categorised. "Each resource is associated with a minimum trust tier required for access," according to Google.

It continues: "The 'Trust Inferer' is a system that continuously analyses and annotates device state. The system sets the maximum trust-tier accessible by the device, and assigns the VLAN [virtual LAN] to be used by the device on the corporate network. These data is recorded in the Device Inventory Service. Re-evaluations are triggered either by state changes or by a failure to receive updates from a device."

The Access Control Engine provides a centralised policy enforcement service referenced by each gateway on the network, which provides access-control decisions (yes or no) based on the access policies, output from the Trust Inferer, the resources requested and the real-time credentials of the user making the request.

The Device Inventory Service is the heart of Google's security architecture. It continuously collects, processes, and logs changes about the state of known devices, which other elements of the security system can reference.

"Resources are accessed via gateways, such as SSH servers, web proxies, or 802.1x-enabled networks," the article continues. "Gateways perform authorization actions, such as enforcing a minimum trust tier or assigning a VLAN."

In the model, even Google-owned and identified devices are not entirely trusted. "A laptop that's centrally managed by the company but that hasn't been connected to a network for some period of time may be out of date. If the operating system is missing some non-critical patches, trust can be downgraded to an intermediate tier, allowing access to some business applications but denying access to others.

"If a device is missing a critical security patch, or its anti-virus software reports an infection, it may only be allowed to contact remediation services. On the furthest end of the spectrum, a known lost or stolen device can be denied access to all corporate resources," suggest the authors.

Such a security architecture, though, requires the management of huge volumes of data, as well as its automated, real-time processing. "Since implementing the initial phases of the Device Inventory Service, we've ingested billions of deltas from over 15 data sources, at a typical rate of about three million per day, totaling over 80 terabytes," say the authors.

"Retaining historical data is essential in allowing us to understand the end-to-end lifecycle of a given device, track and analsze fleet-wide trends, and perform security audits and forensic investigations," they add.

The paper was authored by engineering managers Barclay Osborn and Justin McWilliams, technical writer Betsy Beyer, and programme manager Max Saltonstall.