Google zero-trust security framework goes beyond passwords

Google outlines how BeyondCorp determines whether a device should be allowed to access an application in a perimeter-less network environment

Google zero-trust security framework goes beyond passwords
Thinkstock

With a sprawling workforce, a wide range of devices running on multiple platforms, and a growing reliance on cloud infrastructure and applications, the idea of the corporate network as the castle and security defenses as walls and moats protecting the perimeter doesn’t really work anymore. Which is why, over the past year, Google has been talking about BeyondCorp, the zero-trust perimeter-less security framework it uses to secure access for its 61,000 employees and their devices. 

The core premise of BeyondCorp is that traffic originating from within the enterprise’s network is not automatically more trustworthy than traffic that originated externally. Instead of traditional methods such as VPNs and login credentials to establish trust and verify identity, Google relies on a “tiered access” model, which looks at the user’s individual and group permissions, the user’s privileges as defined by the job role, and the state of the device being used to make the request.

“As resource requests are made from devices, user credentials are verified and the state of the device is queried to assess its risk profile. On successful user verification, access to services is granted only if the assessed risk profile of the device matches the required trusted tier,” Michael Janosko, a manager in Google’s Security Engineering group, and Rosa La Prairie, a product manager for Google Android, wrote in a blog post discussing tiered access.

Tiered access associates internal services with a “trust tier” based on the sensitivity of the data, Google wrote in a whitepaper expanding on the model. Access rights are based on multiple variables—usernames and passwords are just one part—such as device state, user’s group permissions, user’s job role, device behavior, and user behavior, to name a few. 

Traditionally, trust was a binary question: A user was trusted to access an application or data, or the user was not. Devices were automatically trusted if the user was on an internal network and had valid credentials. That security approach doesn’t work so well when attackers can steal credentials, move around within the network, and gain access to applications and services.

Google’s zero-trust networking model treats all users as suspicious and potentially malicious, so tiered access helps to make sure certain conditions are met, such as being authorized to access the service and complying with basic security requirements. An Android device that is fully managed by IT may access more sensitive data via services associated with higher trust tiers. But a BYOD device with a corporate profile would be relegated to a lower trust tier.

Even if the user successfully authenticates to the device, if that device doesn’t have the latest operating system and application patches, access may be denied if the internal service is associated with a sensitive trust tier. Or the device may meet all the requirements, but the user’s job role doesn’t include using that service. Tiered access de-emphasizes traditional passwords in favor of more flexible and accurate means of providing identity.

“Tiered access was implemented in order to provide an access model appropriate for [Google’s] very heterogeneous environment,” Google said in the whitepaper. “It helps ensure the security of corporate resources while allowing users to make informed trade-offs around access and security controls.”

Google uses four tiers: untrusted, basic access, privileged access, and highly privileged access. Untrusted means the device has no access to Google data or services. Basic access refers to services with limited confidential data, while privileged access would be associated with services with confidential information, such as bug tracking. Highly privileged access refers to all corporate services.

Google has been evangelizing the BeyondCorp framework so that it can be used outside of the company, but it isn’t an easy endeavor. Before IT can implement tiered access, it has to compile a comprehensive catalog of all the devices being used and all the users associated with each device. Each of the internal services need to be assigned to a trust tier, and the appropriate level is calculated based on information such as who uses the service, the length of a typical session, what kind of actions are considered normal, and the sensitivity of the data available through the service. IT also needs a gateway or access technology that can evaluate policies and make access decisions.

Google developed custom tools to collect device data and user behavior analytics information. Enterprises interested in tiered access can use security logs, patch management systems, and asset management tools to compile all device attributes and state information into a central repository.

Google Cloud customers can have their own BeyondCorp software-defined perimeter and tiered access via GCP’s Identity-Aware Proxy service. Security startup Duo Security offers Duo Beyond, the first major commercial implementation of BeyondCorp, which lets enterprises differentiate between trusted and untrusted devices, control access to data, and limit remote access.

For most enterprises the reality is that they can’t just focus on defending the corporate network, because a bulk of their sensitive data now lives in cloud applications and many of the critical operations are performed in the cloud. Google shares some of the lessons it learned along the way in its tiered access whitepaper and the earlier BeyondCorp whitepaper. IT teams can use that guidance to develop a flexible access control system that goes far beyond the traditional network perimeter.

Copyright © 2017 IDG Communications, Inc.