What the heck is Zero Trust Security? How is it related to BeyondCorp?

Security teams today are bombarded with marketing around BeyondCorp and Zero Trust security. But what do these terms actually mean, how are the concepts related, and are such initiatives ready for enterprise adoption?

A brief history of BeyondCorp and Zero Trust

Let’s start with a bit of history. Traditional network security architectures were like medieval English castles with strong walls but no defenses once the perimeter was breached.

BeyondCorp, coined by Google, arose from an internal initiative to get rid of Google’s traditional perimeter VPNs and privileged networks after the Aurora attacks of 2009. BeyondCorp espouses three core principles:

• A particular network connection must not determine which services a user can access.
• Access to services is granted based on what we know about a user and the device.
• All access to services must be authenticated, authorized, and encrypted.

Zero Trust Security, coined by Forrester’s John Kindervag who foresaw breaches like the one at Target in 2013, promotes replacing open network designs with one focused on segmentation and central management. Core Zero Trust recommendations include:

• Ensure all resources are accessed securely regardless of location
• Adopt a least-privileged strategy and strictly enforce access control
• Continuously monitor the ecosystem

As you can see in their respective architecture diagrams above, although BeyondCorp sought to replace the VPN while ZeroTrust pushed for stronger segmentation with Next-Gen Firewalls, both concepts essentially say the same thing:

1. Do not rely on location and perimeter for security
2. Enforce granular access controls based on context
3. Continuously monitor and adapt your security policies

What history has taught us

History has taught us that both BeyondCorp and Zero Trust are sound security principles. Massive data breaches in the last few years at Yahoo, OPM, and JPMorgan Chase have convincingly demonstrated that perimeter security models provide only patchy inadequate controls. These breaches could have been prevented had the organizations applied BeyondCorp and Zero Trust. And today, as enterprise applications migrate into borderless environments such as AWS and Azure, it is clear that these security concepts are more relevant than ever.

However, despite clear customer need and significant vendor hype, enterprise adoption of these security models continues to move at a glacial pace. History has some lessons for us here as well. First, too many Zero Trust initiatives make the fundamental mistake of focusing solely on the network layer. As the end-to-end principle tells us, controls should lie close to the users and applications we are securing, rather than in the network infrastructure. And because the network lacks application context, security teams end up adding tremendous complexity to an already overburdened layer.

Second, many BeyondCorp and Zero Trust solutions do not leverage the capabilities that modern clouds such as AWS and Azure provide; they instead force organizations to purchase and manage entirely new sets of duplicate functionality. A common pattern involves setting up a Man-In-The-Middle Cloud DMZ to mediate access instead of using the native capabilities in AWS Load Balancer and Route53. Another pattern involves deploying Next Gen Firewalls and Host-based Microsegmentation instead of using AWS VPCs and Security Groups. As the public cloud’s capabilities and footprint continue to grow, such solutions are forever playing catch up; they soon become redundant and only a few of the included features are kept in use.

The net result has been that many enterprise security practitioners see Zero Trust and BeyondCorp initiatives as too complicated and expensive to roll out for their organizations.

Building it right

So, how do we make Zero Trust and BeyondCorp initiatives successful at organizations of all scales and sophistication? How do we make borderless access controls simple yet secure enough for a regular security team to adopt and manage?

This is a problem the team at Banyan Security has spent a lot of time and energy agonizing about. We’ve interviewed 100s of security professionals across industry verticals, based on which we propose four new guidelines for security teams charged with deploying Zero Trust and BeyondCorp initiatives:

1. Make no changes to the network. Your security initiative should not require changes to network management in order to roll out Zero Trust. The network is wrong layer for such security controls.
2. Incrementally roll out new security measures without changing apps. A Zero Trust solution should have the capability to be rolled out one brownfield service at a time, without mandating organization-wide or application changes.
3. Architect solutions that go beyond the perimeter. While securing the perimeter is an absolute requirement, security teams should not stop there. Zero Trust architectures should have the ability to manage controls down to individual users and devices, and the services and hosts they access.
4. Leverage existing enterprise tools. The ideal Zero Trust and BeyondCorp architecture should leverage existing enterprise investments via integrations. This applies not just to leveraging public cloud platforms but also to using existing identity providers, enterprise device managers and workload orchestrators.

These are likely self-evident truths to many security practitioners, and we firmly believe that security teams and solutions that follow them are the key to Zero Trust and BeyondCorp success.

In subsequent posts we’ll discuss how the Banyan Zero Trust Platform follows these guidelines to enable organizations of all sizes to roll out Zero Trust and BeyondCorp security initiatives.