Preparing for a BeyondCorp world at your company

A while back I shared some thoughts on BeyondCorp, the security approach we use at Google that allows employees to work from any network, quickly and easily. Since then, we received lots of great feedback, including many who asked, “How do I start?” They’re looking for step-by-step help in applying these context-based access practices in their particular organizations, so we’ve created a series about some of our best practices at Google.

Know your people. Know your devices.

The first step to moving from a privileged corporate network (usually with a VPN at its core) to a zero-trust network is to know your people and know your devices. When the network no longer provides the trust required to access critical company information, we instead turn to the information we have about individual employees and their devices. Without a reliable, up-to-date set of data about the people and their machines, we can’t make good decisions about access.

On the employee side, at Google, this required restructuring our job role hierarchy. We had to reshape our array of job classifications so we could more accurately capture what people were actually doing day to day, and what sort of access they required by role. We had to answer some tough but very logical questions like:

• Who needs to see internal bug information?
  
• Who needs access to source code?
  
• Who needs to track customer relationships?
  

Sorting all this out required changes to our existing jobs, sometimes to simplify and combine existing roles that looked similar to each other. Elsewhere, we needed to change classification to make sure we captured differences between groups of employees who might be performing different jobs but happen to share a job role in our tracking system.

Alongside that, we had to make sure we had accurate, timely information about all the devices Googlers were using. We do not want to extend trust to a person, only to have them use an infected device and inadvertently share the information they have access to with an attacker. The devices are just as important as the people in this access scheme.

Keep a single inventory of record

When we started, Google had numerous systems to track and understand our device inventory—Asset Management tools, DHCP servers, Wireless Access logs, tech support systems, and more—but none of them were truly comprehensive. We ended up building a meta-inventory service that ingests data from these other systems, brought it all together, and correlated it into a single inventory. Without this step, we would have had both conflicting records and multiple instances of one device across different systems, without the ability to tell when we might accidentally have more than one copy.

Creating this new master inventory service took a large investment of time and effort, but has given us a much more unified look at our multitude of devices, as well as what they are doing. Now that we’ve got this picture more filled in, we can make trust evaluations based on the state of a device, looking at its installed software, patch level, and other characteristics.

Next steps

Here are a few suggested next steps based on our own experience and best practices.

1. Understand what apps you use internally
   
2. Decide on, or refine security policies for accessing these services
   
3. Know who your people are and what they do
   
4. Decide who is allowed to get to what
   
5. Put in place Identity-based access controls (such as Identity-Aware Proxy)

More to come

There’s much more to the process of building your trust model around people and devices as opposed to networks, and I will cover further steps in future posts. If you have looked at Google’s BeyondCorp model—or others advocating zero-trust networks—and think that you’d like to build something similar, take the time to build a solid understanding of what jobs people are doing and the health of their devices. These two pieces form a critical foundation for context-aware access control.