Product and service reviews are conducted independently by our editorial team, but we sometimes make money when you click on links. Learn more.
 

Google’s Zero Trust 'BeyondCorp' Infrastructure Shows Future Of Network Security

By - Source: Google
Tags :

Last year, Google started changing its network security policies to a new model of “zero trust,” which treats its own internal network as the insecure Internet. Google released a new paper detailing how this new model works for its network security policies.

The new model, called “BeyondCorp,” should put an end to conventional perimeter-breaching attacks, which can expose most computers on a network due to a lack of strong device-oriented security.

"Unlike the conventional perimeter security model, BeyondCorp doesn’t gate access to services and tools based on a user’s physical location or the originating network; instead, access policies are based on information about a device, its state, and its associated user. 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,” said Google security engineers in a recent paper.

BeyondCorp Components

The BeyondCorp infrastructure contains multiple components that all play a role in increasing the security of the network.

Devices And Hosts

The first part in implementing BeyondCorp is choosing a basic inventory of devices and “hosts,” which represent specific versions of certain software that can be trusted to be secure.

Tiered Access

After a given set of devices is selected, Google enables “tiered access” for devices and resources. Each device would need to have the same level or higher of trustworthiness as the resources that need to be accessed. This is useful to avoid having employees access highly sensitive information from a PC or mobile device that has low security. The more sensitive a resource is, the more secure the device and the operating system on it need to be, before it can be accessed.

Device Inventory Service

This service provides a cycle of updates, vulnerability scans, digital certificates, and general asset management for devices. It also retains historical data, allowing for security audits later on and to keep track of device life cycles.

Types Of Data

Google puts data in two categories: observed and prescribed. The observed data includes items such as:

  • The last time a security scan was performed on the device, in addition to the results of the scan
  • The last-synced policies and timestamp from Active Directory
  • OS version and patch level
  • Any installed software

Prescribed data is manually maintained by IT operations, and includes:

  • The assigned owner of the device
  • Users and groups allowed to access the device
  • DNS and DHCP assignments
  • Explicit access to particular VLANs

Google uses all of this data to see where there is a conflict, which could point to a possible breach.

Data Processing

To keep the Device Inventory Service up to date, all data must be transformed into a common data format. Afterwards, the data is correlated to create unique device specific records. Google warned that this is not an easy task, as it may be hard to correlate certain identifiers such as digital certificates, asset IDs, and hard drive serial numbers to describe a single device. Complications can also arise if these identifiers are manually added incorrectly into the system.

Trust Evaluation

To quality for a high level of trust, a device would need to meet all of the following requirements, and possibly more:

  • Be encrypted
  • Successfully execute all management and configuration agents
  • Install the most recent OS security patches
  • Have a consistent state of data from all input sources

Interestingly enough, although Google has been saying publicly that we shouldn’t worry too much about the Stagefright vulnerabilities in Android, the company itself was at the time banning devices with these vulnerabilities from accessing its network.

Exceptions

Google’s BeyondCorp infrastructure has some exceptions for its devices as well, which is meant to reduce the deployment of policy changes. For instance, Google could override the access policy of certain devices, either to completely block them from the network (before the vulnerability scanners are updated to account for new zero-days affecting those devices) or to permit untrusted devices to connect to a lab network. Google also said that IoT devices may be harder to secure, which is why they will be assigned their own trust tier.

Deployment

Google gradually rolled out the BeyondCorp access policy system to minimize disruption of its employees’ work. After the team in charge of deploying BeyondCorp verified the workflows of lower-tiered devices, they moved on to apply fine-grained restrictions to higher trust tiers. This continued until the trust tiers were assigned retroactively to all of Google’s devices.

Google discovered that it was actually easier to secure mobile devices because of the lack of legacy protocols and access methods, and because all communications are HTTP-based, which can be secured cryptographically.

Biggest Challenges

One of the biggest challenges Google met when deploying BeyondCorp was the incorrect data about the devices entering the network, which would cause them to unintentionally lose access to corporate resources. Device records can also be corrupted when certain components are changed in a device. To solve this, Google has focused on increasing the accuracy of inventory data, which has also led to an increase in devices that can be updated with the latest security patches.

Google also found that it needs to have just the right amount of communication during such changes. Otherwise, under-communicating the changes could leave users confused, whereas over-communicating could lead them to find excuses for exemptions.

Disaster Recovery

To avoid a catastrophic failure of the BeyondCorp infrastructure that would leave everyone locked out of their devices, Google implemented disaster recovery practices that can be employed only by an “extremely small subset of privileged maintainers.” In case of an emergency, a company also has the ability to push fine-grained changes to the access policy that would allow the maintainers to start the recovery process.

Google believes that BeyondCorp improved the company network’s security significantly without sacrificing usability. It also thinks that the principles of this model can be used for other companies’ networks, as well.

Lucian Armasu is a Contributing Writer for Tom's Hardware. You can follow him at @lucian_armasu. 

Follow us on FacebookGoogle+RSSTwitter and YouTube.

Comments