Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

12/13/2017
04:55 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Google Sheds Light on Data Encryption Practices

Google explains the details of how it secures information in the cloud and encrypts data in transit.

Following a year of major cyberattacks and security threats, Google has published two whitepapers to explain how it secures data. One focuses on encryption of data in transit; the other on service-to-service communication using Application Layer Transport Security (ALTS).

Google gets a lot of questions from customers on how it protects data, says Maya Kaczorowski, Google Cloud security and privacy product manager. Today's release details the steps taken to protect authenticity, integrity, and privacy by verifying data sources, ensuring data arrives unchanged, and keeping data confidential while in transit.

Encryption in transit refers to "how data moves from a user to Google, and how it moves within Google's infrastructure," she explains. When a user sends data to the Google Cloud, it's encrypted in transit by default using HTTPS and TLS. Both of these are common practice; Google introduces more security for data traveling outside its infrastructure.

Google Cloud encrypts and authenticates all data in transit, at multiple network layers, when it moves outside physical boundaries not under Google's control. Data within these boundaries is authenticated but not always encrypted because strong security measures are already in place.

"When running at Google's scale, performance is important," Kaczorowski says. "Different modes of protection we use depend on the threat model and performance requirements that we have."

To protect against potential threats, she continues, Google assumes the external wide-area network "is only semi-trusted." Encrypting data protects it from active adversaries who could spy, inject, or alter traffic on the wire, Kaczorowski explains in a blog post on today's release.

On a network level, Google Cloud's virtual network infrastructure automatically encrypts data moving between virtual machines if it crosses a physical boundary Google doesn't control.

"Once the data is inside Google, the first thing to understand is not all data in transit within Google is protected the same way," says Kaczorowski.

The ALTS protocol, discussed in detail in the second whitepaper, is a mutual authentication and transport encryption system. Google usually uses it to secure Remote Procedure Call (RPC) communications from service to service within its infrastructure. Each of these internal services has a service account identity with cryptographic credentials used for authentication.

ALTS is similar to TLS but designed specifically for Google's data centers. It relies on two protocols, the Handshake and Record protocols, both of which dictate how sessions are established, authenticated, encrypted, and resumed, as explained in the paper.

The trust models of TLS with HTTPS semantics, and ALTS, are significantly different, Google says in the paper. The former binds server identities to a specific name and associated naming schemes. The latter uses the same identity for multiple naming schemes, adding flexibility and simplifying the process of load balancing, microservice replication, and scheduling between hosts. ALTS is simpler in design and implementation, Google says, making it easier to monitor for bugs and vulnerabilities using manual source code inspection or fuzzing.

There are a few trade-offs to using ALTS over TLS, the company points out. For example, it's not designed to conceal the internal services communicating; as a result, it doesn't encrypt handshake messages to hide identities.

The ALTS handshake protocol is also susceptible to Key Compromise Impersonation attacks. If an attacker compromises the Diffie-Hellman key used during the handshake, or the resumption key of a workload, they can use that key to make illegitimate workloads appear authentic.

On top of default protections, Google lists additional options to encrypt data in transit: IPsec tunnels, free and automated TLS certificates, and Istio, an open-source service mesh developed by Google and other companies, including Lyft and IBM, to help with service discovery.

Related Content:

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Aviation Faces Increasing Cybersecurity Scrutiny
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/22/2019
Microsoft Tops Phishers' Favorite Brands as Facebook Spikes
Kelly Sheridan, Staff Editor, Dark Reading,  8/22/2019
MoviePass Leaves Credit Card Numbers, Personal Data Exposed Online
Kelly Sheridan, Staff Editor, Dark Reading,  8/21/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2016-6154
PUBLISHED: 2019-08-23
The authentication applet in Watchguard Fireware 11.11 Operating System has reflected XSS (this can also cause an open redirect).
CVE-2019-5594
PUBLISHED: 2019-08-23
An Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") in Fortinet FortiNAC 8.3.0 to 8.3.6 and 8.5.0 admin webUI may allow an unauthenticated attacker to perform a reflected XSS attack via the search field in the webUI.
CVE-2019-6695
PUBLISHED: 2019-08-23
Lack of root file system integrity checking in Fortinet FortiManager VM application images of all versions below 6.2.1 may allow an attacker to implant third-party programs by recreating the image through specific methods.
CVE-2019-12400
PUBLISHED: 2019-08-23
In version 2.0.3 Apache Santuario XML Security for Java, a caching mechanism was introduced to speed up creating new XML documents using a static pool of DocumentBuilders. However, if some untrusted code can register a malicious implementation with the thread context class loader first, then this im...
CVE-2019-15092
PUBLISHED: 2019-08-23
The webtoffee "WordPress Users & WooCommerce Customers Import Export" plugin 1.3.0 for WordPress allows CSV injection in the user_url, display_name, first_name, and last_name columns in an exported CSV file created by the WF_CustomerImpExpCsv_Exporter class.