Google reveals its servers all contain custom security silicon
Even the servers it colocates (!) says new doc detailing Alphabet sub's security secrets
Google has published a Infrastructure Security Design Overview that explains how it secures the cloud it uses for its own operations and for public cloud services.
Revealed last Friday, the document outlines six layers of security and reveals some interesting factoids about the Alphabet subsidiary's operations, none more so than the revelation that “we also design custom chips, including a hardware security chip that is currently being deployed on both servers and peripherals. These chips allow us to securely identify and authenticate legitimate Google devices at the hardware level.”
That silicon works alongside cryptographic signatures employed “over low-level components like the BIOS, bootloader, kernel, and base operating system image.”
“These signatures can be validated during each boot or update,” the document says, adding that “the components are all Google-controlled, built, and hardened. With each new generation of hardware we strive to continually improve security: for example, depending on the generation of server design, we root the trust of the boot chain in either a lockable firmware chip, a microcontroller running Google-written security code, or the above mentioned Google-designed security chip."
Another interesting nugget of information the document reveals is that “Google additionally hosts some servers in third-party data centers,” a fact mentioned so the company can explain that when it works with others' bit barns it puts in place its own layers of physical security such as “independent biometric identification systems, cameras, and metal detectors.”
The document goes on to explain that Google's fleet of applications and services encrypt data before it is written to disk, to make it harder for malicious disk firmware to access data.
Disks get the following treatment:
We enable hardware encryption support in our hard drives and SSDs and meticulously track each drive through its lifecycle. Before a decommissioned encrypted storage device can physically leave our custody, it is cleaned using a multi-step process that includes two independent verifications. Devices that do not pass this wiping procedure are physically destroyed (e.g. shredded) on-premise.
Elsewhere, the document describes client security which starts with universal second factor authentication and then sees the company scan employees' devices to “ensure that the operating system images for these client devices are up-to-date with security patches and … control the applications that can be installed.”
“We additionally have systems for scanning user-installed apps, downloads, browser extensions, and content browsed from the web for suitability on corp clients,” the web giant continues.
“Being on the corporate LAN is not our primary mechanism for granting access privileges. We instead use application-level access management controls which allow us to expose internal applications to only specific users when they are coming from a correctly managed device and from expected networks and geographic locations.”
Also explained are the automated and manual code review techniques Google uses to detect bugs in software its developers write. The manual reviews “are conducted by a team that includes experts across web security, cryptography, and operating system security. The reviews can also result in new security library features and new fuzzers that can then be applied to other future products.”
There's also this description of the lengths Google goes to in its quest to protect source code:
Google’s source code is stored in a central repository where both current and past versions of the service are auditable. The infrastructure can additionally be configured to require that a service’s binaries be built from specific reviewed, checked in, and tested source code. Such code reviews require inspection and approval from at least one engineer other than the author, and the system enforces that code modifications to any system must be approved by the owners of that system. These requirements limit the ability of an insider or adversary to make malicious modifications to source code and also provide a forensic trail from a service back to its source.
There's plenty more in the document, like news that Google's public cloud runs virtual machines in a custom version of the KVM hypervisor. Google also boasts in the document that it is “the largest submitter of CVEs and security bug fixes for the Linux KVM hypervisor.” We also learn that the Google cloud rests on the same security services as the rest of its offerings.
There's also an explanation of the company's internal service identity and access management scheme, detailed in the diagram below, plus news that “we do not rely on internal network segmentation or firewalling as our primary security mechanisms.” That's a little at odds with current interest in network virtualisation and microsegmentation.
Google's Service Identity and Access Management scheme
The company's also published documents detailing each aspect of security discussed in the main document. They're listed and linked to at the end of the master document. ®
Sponsored: What next after Netezza?