If you’re familiar with the articles about Google’s BeyondCorp network
security model published in ;login: [1-3] over the past two years, you
may be thinking, “That all sounds good, but how does my organization
move from where we are today to a similar model? What do I need to do?
And what’s the potential impact on my company and my employees?” This
article discusses how we moved from our legacy network to the BeyondCorp model—changing the fundamentals of network access—without reducing the company’s productivity.
Traditional security models use a binary, all-or-nothing access model where access is granted solely on the basis of machine, user, and service membership into an authentication authority, such as active directory or LDAP.
Google is taking a different approach and using tiered access as one tool to address these challenges. In contrast to traditional models, tiered access provides more granular control. The level of access given to a single user or a single device may change over time based on device measurements allowing security to set access policy that considers deviations from intended device state.
At Google, the Technical Infrastructure organization manages access for the devices used by more than 61,000 employees while protecting against sophisticated adversaries. Below we outline the model that Google has adopted and continues to evolve as it’s rolled out. The first phase of roll-out has enabled access from mobile devices, while subsequent phases will expand enrollment to cover the entire fleet of Google devices.
Millions of companies entrust Gmail to handle their emails. In this RSA 2017 talk, we will discuss the nuances surrounding company-specific attacks and highlight the defenses we put in place to counter those threats. The insights shared will inform those looking to tackle the complex security challenges posed by email within their own organizations.
The SMTP protocol is responsible for carrying some of users most intimate communication, but like other Internet protocols, authentication and confidentiality were added only as an afterthought. In this work, we present the first report on global adoption rates of SMTP security extensions, including: STARTTLS, SPF, DKIM, and DMARC. We present data from two perspectives: SMTP server configurations for the Alexa Top Million domains, and over a year of SMTP connections to and from Gmail. We find that the top mail providers (e.g., Gmail, Yahoo, and Outlook) all proactively encrypt and authenticate messages. However, these best practices have yet to reach widespread adoption in a long tail of over 700,000 SMTP servers, of which only 35% successfully configure encryption, and 1.1% specify a DMARC authentication policy. This security patchwork — paired with SMTP policies that favor failing open to allow gradual deployment — exposes users to attackers who downgrade TLS connections in favor of cleartext and who falsify MX records to reroute messages. We present evidence of such attacks in the wild, highlighting seven countries where more than 20% of inbound Gmail messages arrive in cleartext due to network attackers.
The security of online user accounts is often protected by no more than a weak password. We present “Security Key”, a second-factor device based on open standards that protects users against phishing and man-in-the-middle attacks. The user carries a single device and can self-register it with any online web service that supports the standard. The devices are simple to implement and deploy, are not encumbered by patents, are simple to use, privacy preserving, and secure against strong attackers. We have shipped support for Security Keys in one of the mainstream web browsers. In addition, multiple device vendors produce security keys. In this work, we demonstrate that Security Keys lead to both an increased level of security and user satisfaction by analyzing a two year deployment which began within our 50,000 person corporation and has extended to our consumer-facing web applications. The Security Key design has been standardized by the FIDO Alliance, an organization with more than 170 member companies spanning the industry.
This article details the implementation of BeyondCorp’s front end infrastructure. It focuses on the Access Proxy, the challenges we encountered in its implementation, and the resulting lessons we learned in its design and rollout. We also touch on some of the projects we’re currently undertaking to improve the overall user experience for employees accessing internal applications. In migrating to the BeyondCorp model (previously discussed in BeyondCorp: A New Approach to Enterprise Security and BeyondCorp: Design to Deployment at Google), Google had to solve a number of problems. One particular challenge was figuring out how to enforce company policy across all our internal-only services. A conventional approach might integrate each back end with the device Trust Inferer in order to evaluate applicable policies; however, this approach would significantly slow the rate at which we’re able to launch and change products. To address this challenge, Google implemented a centralized policy enforcement front end Access Proxy (AP)–to handle coarse-grained company policies. Our implementation of the AP is generic enough to let us implement logically different gateways using the same AP codebase. At the moment, Access Proxy implements both the Web Proxy and the SSH gateway components, according to the terminology used in the previous article. As the AP was the only mechanism that allowed employees to access internal HTTP services, all internal services were required to migrate behind the AP. Unsurprisingly, attempting to deal with only HTTP requests proved inadequate, so we had to provide solutions for additional protocols, many of which required end-to-end encryption (e.g. SSH). These additional protocols necessitated a number of client-side changes to ensure that the device was properly identified to the AP. The combination of the AP and an Access Control Engine (a shared ACL evaluator) for all entry points provided a couple of main benefits: a common logging point for all requests allowed us to perform forensic analysis more effectively, and we were also able to make changes to enforcement policies much more quickly and consistently.
Since the publication of OpenFlow: Enabling Innovation in Campus Networks in 2008, there has been a lot of published work and experience with SDN and OpenFlow in large networks and in datacenters, including at Google. In this article we will discuss an open source SDN controller, FAUCET. FAUCET was created to bring the benefits of SDN to a typical enterprise network and has been deployed in various settings, including the Open Networking Foundation, which runs an instance of FAUCET as their office network. FAUCET delivers high forwarding performance using switch hardware, while enabling operators to add features to their networks and deploy them quickly, in many cases without needing to change (or even reboot) hardware – and interoperates with neighboring non-SDN network devices.