Skip navigation
Industry Events

RSAC 2017: BeyondCorp - How Google Protects Its Corporate Security Perimeter Without Firewalls

The RSA Conference 2017 is filled with an awful lot of noise, but many of the same themes resonated throughout the keynotes, sessions and vendor messaging.

One of those themes is around protecting the new perimeter-less enterprise IT model, using a new approach to security. Google’s Director of Information Security Heather Adkins and Site Reliability Engineering (SRE) Manager Rory Ward gave a talk about how Google solved this problem internally.

Moving to a Mobile, Distributed Workforce

Your enterprise is your castle - with the sensitive data inside, and a strong perimeter on the outside. Decades ago, you would typically connect hardware and software in your environment and enable firewalls to protect it all.

But as our workforces become more mobile, the inhabitants of the castle (your employees) started working outside of the castle. They needed a way to work remotely, and a way to work collaboratively with other people outside of the firewall.

Nowadays, many use the Swiss-cheese approach; building walls inside of the castle and using network segmentation, which can be difficult to maintain. Google’s network was similar, but soon, their challenges grew more and more complex as they struggled to support their employees working from all over the world.

They used a virtual private network (VPN) to extend the castle perimeter to the most popular mobile device of choice - the laptop. While users know VPNs, they don’t particularly like them - they’re unreliable, disconnect, tend to break often, and are heavyweight.

Google’s employees wanted to use their new tablets, laptops and phones. These devices are mobile and escape the network perimeter. Supporting these devices securely has become a business differentiator, allowing users to be more innovative, productive and seamlessly do work from all over the world.

What if Walls Never Worked?

This made Google question: What if walls never worked? What if firewalls never worked?

Google BeyondCorp - Walls Don't Work

Imagine a cosmopolitan city and busy road, where your employees are mingling with other people on the street. You can’t tell if they’re authorized or unauthorized by only their location on the street. The same goes for your users, based on the network they’re coming from.

These are Google’s BeyondCorp Principles:

  1. Connecting from a particular network must not determine which services you can access
  2. Access to services is granted based on what we know about you and your device
  3. All access to services must be authenticated, authorized and encrypted

Which helps Google’s security team achieve their goal of having every employee work successfully from untrusted networks, without the use of a VPN.

Implementing BeyondCorp

Rory explained how Google implemented BeyondCorp at Google and externalized their single sign-on (SSO) and access proxy. Now it is globally deployed and fully redundant, and took about two to three years to implement.

They relied on two major aspects:

  1. First, they got to know their users with a detailed user inventory that tracked users throughout their lifecycle and job function changes, and ensured that the information is updated as they move through the organization.
  2. Second, they got to know their devices with a device inventory that tracked devices from procurement to provisioning to end of life. They also track what happens when a device gets repaired or upgraded.

They also built a trust repository for their devices using device certificates that ingests data from about 20 different data sources about what the device is doing on the network.

Google’s security team also keeps a policy file that defines how to define trust for certain devices (i.e., if a device has been on the network for at least 20 days, or they may automatically mark mobile phones as low-trust). The trust of a particular device can also go up or down depending on what it has done, or what the policy says.

Google BeyondCorp - Access Control Engine

Rory referred to their ‘access control engine’ as a combination of an indication of who the user is, what the device is, and the resource it’s trying to get access to. For example, to access source code systems, you must be a full-time Google employee working in Engineering, using a fully-trusted desktop computer.

Migrating BeyondCorp

They deployed an unprivileged network in all 200 Google buildings, and compared the traffic to their new, no-privilege network. By sniffing their own traffic and looking at all user SAML traffic in the company via all network routers from their old network, they figured out what traffic would work on the new network, and what wouldn’t.

They installed an agent on every device and looked at every packet from that device, replaying it on the unprivileged network. They also built a migration pipeline, using big data to figure out what traffic would be on the new network. They moved tens of thousands of devices onto the new network.

BeyondCorp Outreach - White Papers

Google has released three white papers to help educate the industry on what they’re doing, why, and how:

Check out each of the abstracts above, as well as a link to download the full papers in PDF format from the Research at Google Publications library of resources.

BeyondCorp Deployment: Lessons Learned

They learned that they needed to get and retain executive support, especially since, in some cases, they would have to ask users to change how they operate on a day-to-day basis.

The clear wins included making IT simpler and more secure, as well as much happier users that were able to work from anywhere in the world. They also learned that data quality is key, and that they needed to make the migration painless for users.

Communication with their users was key to let them know what was happening, in addition to getting feedback from users on how they’re experiencing the migration to alleviate any distrust.

Additionally, they needed to run highly reliable systems, which is where site reliability engineering comes in. If the access policy doesn’t work, no one gets access.

Applying BeyondCorp

Others learn from Google’s example to apply BeyondCorp principles in their own organizations’ environments:

  1. Have zero trust in your network
  2. Base access decisions on what you know about the user and device
  3. Migrate carefully so as not to break existing users

Duo’s newest edition launched earlier this month is the first commercial implementation of Google’s BeyondCorp model. Duo Beyond allows you to identify corporate vs. personal devices with easy certificate deployment, block untrusted endpoints, and give your users secure access to internal applications without using VPNs.

All in addition to Duo’s easy-to-use two-factor authentication, secure single sign-on (SSO) and phishing vulnerability assessments.