How Google Does It: Network security in a nutshell

Ever wondered how Google does security? As part of our “How Google Does It” series, we’ll share insights, observations, and top tips about how we approach some of today's most pressing security topics, challenges, and concerns — straight from Google experts. In this edition, Cesar Ghali, Google’s network security tech lead, and Mike Schiffman, GUSTO application security tech lead (and former network security tech lead), discuss the top challenges facing network security and share how Google approaches tackling them.

At Google, we consider our fundamental network security perimeters to be state-of-the-art, relying on layers of defense — defense-in-depth — to help us protect our network from external attacks. We strive to evolve and adapt as we grow as an organization, relying on clever engineering and economies of scale to keep up and achieve the wins we have.

Starting from a defense-in-depth mindset, while we do employ firewalls and network-layer access control lists, we do not rely solely on the traditional “castle-and-moat” security model. Trust is never derived from network location and being inside the corporate network grants no inherent privileges.

Instead, Google relies on a robust Zero Trust model requiring every user, device, or service to identify and authenticate before it can be considered for access. Additionally, we allow only authorized protocols that meet our security requirements on our network.

We route all traffic through Google Front End (GFE) servers to help us detect and stop malicious requests and distribute denial-of-service (DDoS) attacks. We also routinely monitor the network to detect anomalies, exploitations, and unauthorized access.

On top of that, we employ several security measures to help ensure the authenticity, integrity, and privacy of data at rest, in use, and in transit. In particular, Google encrypts and authenticates data when in transit, automatically applying default protections.

For example, Transport Layer Security (TLS) encryption is used for traffic between the user and Google, while Application Layer Transport Security (ALTS) — our authentication and transport encryption system — is used for traffic between services in our infrastructure.

With that in mind, let’s explore some of the biggest challenges facing Google today and how they are shaping the near and long-term future of our network security programs.

Increasing complexity

The huge demand for today’s vast and myriad Internet-connected devices to run at scale and interact requires delivering the infrastructure and resources they need to the right location, anywhere in the world. Building such complex, distributed systems that evolve over time can be a breeding ground for vulnerabilities.

At Google, we prioritize simplicity to reduce or eliminate complexity. We integrate network security early in the design phase, using foundational security principles and invariants to create architectures that are fundamental, intuitive, and robust.

For example, our Zero Trust security framework in Chrome Enterprise Premium shifts access decisions from the network perimeter to individual users and devices, helping us to reimagine our security architecture and enable employees to work more securely in their browser. Solutions like these, which focus on fundamentals and simplicity, have long been a driving force behind shaping our network security programs.

No more ‘one-size-fits-all’

For Google to grow as an organization, we pioneered many technologies to solve industry problems. However, as the use of cloud technologies and services has increased, we have had to work hard to adapt and evolve to keep up with the needs of our customers.

On one hand, the fact that many of our systems and infrastructure are bespoke gives us an advantage for handling competing requirements that few organizations have. For example, middleboxing — the use of network devices like firewalls or load balancers that transform, inspect, and filter traffic — is still widely used and beneficial in network security.

However, this approach implicitly breaks end-to-end encryption guarantees. Given our bespoke infrastructure, we have had the ability to design our systems in a way that delivers the necessary instrumentation and monitoring while still maintaining end-to-end encryption.

On the other hand, having our own proprietary protocols isn’t always desirable, especially in cases where we need interoperability. In addition, customers and regulators have many requirements for how their data is secured in our network.

The combination of those factors drove us to build flexible network security and agile cryptographic controls, allowing ongoing upgrades of cryptographic algorithms and increasing key sizes, to ensure that we can meet a wide range of compliance and data privacy needs.

Top-shelf threat actors

In pursuing our mission to organize the world's information and make it universally accessible and useful, we have also become a significant target. We face threat actors who carry out noisier DDoS and ransomware attacks, and also stealthier, under-the-radar attackers, such as advanced persistent threats (APTs) looking to gain an undetected presence in our networks.

As such, we are always working to solve a new generation of vulnerabilities and threats — even those that have yet to arrive.

For example, we are also already taking proactive steps to help secure our networks and data against potential quantum computing threats. We’ve been using post-quantum cryptography (PQC) techniques since 2016 to combat Store Now, Decrypt Later (SNDL) attacks, where threat attackers harvest encrypted network traffic for when classical encryption eventually becomes vulnerable.

In general, organizations in this new era of security should maintain focus on network security fundamentals, no matter what threat they’re facing.

This article includes insights from the Cloud Security Podcast episode, “From Blueboxing to LLMs via Network Security at Google.”