Virtually every company today uses firewalls to enforce perimeter
security. However, this security model is problematic because, when
that perimeter is breached, an attacker has relatively easy access to a
company’s privileged intranet. As companies adopt mobile and cloud technologies,
the perimeter is becoming increasingly difficult to enforce. Google
is taking a different approach to network security. We are removing the
requirement for a privileged intranet and moving our corporate applications
to the Internet.
The goal of Google’s BeyondCorp initiative is to improve our security
with regard to how employees and devices access internal applications.
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.
We present an overview of how Google transitioned from traditional security infrastructure
to the BeyondCorp model and the challenges we faced and the lessons we learned in the process.
For an architectural discussion of BeyondCorp, see .
Google’s employees are spread across the globe, and with job functions
ranging from software engineers to financial analysts, they require a broad
spectrum of technology to get their jobs done. As a result, we manage a fleet
of nearly a quarter-million computers (workstations and laptops) across four
operating systems (macOS, Windows, Linux, and Chrome OS).
Our colleagues often ask how we’re able to manage such a diverse fleet. Do
we have access to unlimited resources? Impose draconian security policies
on users? Shift the maintenance burden to our support staff?
The truth is that the bigger we get, the more we look for ways to increase
efficiency without sacrificing security or user productivity. We scale our
engineering teams by relying on reviewable, repeatable, and automated
backend processes and minimizing GUI-based configuration tools. Using and
developing open-source software saves money and provides us with a level
of flexibility that’s often missing from proprietary software and closed
systems. And we strike a careful balance between user uptime and security
by giving users freedom to get their work done while preventing them from
doing harm, like installing malware or exposing Google data.
This paper describes some of the tools and systems that we use to image,
manage, and secure our varied inventory of workstations and laptops . Some
tools were built by third parties—sometimes with our own modifications to
make them work for us. We also created several tools to meet our own
enterprise needs, often open sourcing them later for wider use. By sharing
this information, we hope to help others navigate some of the challenges
we’ve faced—and ultimately overcame—throughout our enterprise fleet
Previous articles in the BeyondCorp series discuss aspects of the
technical challenges we solved along the way [1–3]. Beyond its purely
technical features, the migration also had a human element: it was
vital to keep our users constantly in mind throughout this process. Our goal
was to keep the end user experience as seamless as possible. When things
did go wrong, we wanted users to know exactly how to proceed and where to
go for help. This article describes the experience of Google employees as they
work within the BeyondCorp model, from onboarding new employees and
setting up new devices, to what happens when users run into issues.
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.