BSidesSF 2017 - BeyondCorp: Beyond “fortress” security (Neal Mueller & Jeff Peck)

### Overview In this BSidesSF 2017 presentation, Neal Mueller and Jeff Peck detail Google’s BeyondCorp initiative, a zero-trust security framework initiated in 2011 to replace traditional perimeter-based "castle-and-moat" enterprise architectures. Motivated by the realities of mobile workforces, contractors, cloud workloads, and increasing device diversity, Google sought to eliminate dependence on VPNs and internal network trust. Instead of trusting devices simply because they reside on an internal network, BeyondCorp operates on the principle that no network is trusted, requiring explicit authentication and authorization for every single request.

### Key Topics - **Flaws of the Castle Approach**: Traditional perimeter security relies heavily on firewalls, site-to-site VPNs, and network segmentation. Once an attacker or contractor breaches the perimeter, they often gain unintended lateral access across the corporate network. Furthermore, VPNs introduce administrative overhead, slow connections, and do not protect against phishing or malware (such as Zeus) operating on authenticated endpoints. - **Core Principles of BeyondCorp**: The architecture relies on three primary tenets: IP addresses are never used to grant trust; access to services is determined by granular knowledge of the user and device; and every connection must be authenticated, authorized, and fully encrypted end-to-end. - **Architecture and Components**: Access is mediated through centralized access proxies (internally referred to at Google as UberProxy). Rather than connecting directly to backend applications, traffic—including HTTP and wrapped SSH connections—passes through the proxy, coordinating with single sign-on (SSO) and a centralized access control engine that enforces fine-grained policies. - **User and Device Inventories**: Strong authentication requires knowing both the user identity and device state. Google utilizes physical security keys (internally called "nubby") for phishing-resistant multi-factor authentication. Device trust relies on managed certificate authorities, TPMs/keystores, and an automated inventory tracking system collecting signals such as binary whitelisting (e.g., Bit9), OS patch versions, and ownership associations into a trust repository.

### Technical Details & Implementation Google managed the migration by avoiding an in-place modification of existing open networks. Instead, they built a new unprivileged VLAN where devices cannot communicate with peers or reach server backend networks directly, only reaching designated access proxies. Devices authenticate to this network using 802.1X and client certificates.

To prevent business disruption, Google avoided cutting off protocols blindly. They analyzed NetFlow logs and router data, alongside a client-side iptables monitoring application, to identify legacy workflows (such as RDP, Java RMI, NFS, and CIFS). Non-web traffic was remediated, deprecated, or wrapped into HTTP for proxy traversal. Migration was automated through a data pipeline: when client telemetry showed clean, compatible network usage for 30 consecutive days, the device was automatically assigned to the unprivileged network upon its next network check-in.

### Takeaways Successfully implementing zero-trust at scale requires organizational buy-in from leadership down to tech support, as well as exceptionally high data quality in device and user inventories. Migration must be data-driven and gradual, ensuring user workflows succeed before transitioning devices. Finally, because centralized proxies and policy engines become the sole path to critical corporate applications, high reliability and continuous cross-functional communication are essential to prevent operational disruptions.