Cloud

8/6/2018
02:40 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Google Details Tech Built into Shielded VMs

Specialized virtual machines, recently released in beta mode, ensure cloud workloads haven't been compromised.

Google recently rolled out in beta specialized virtual machines, called Shielded VMs, so account holders on Google Cloud Platform (GCP) could run workloads without fear of running compromised code.

Now the company is publishing details on how Shielded VMs keep the cloud secure from attack vectors, including guest system firmware, guest OS via malicious guest-VM kernel or user-mode vulnerabilities, and malicious customer insiders tampering with guest VM images. Threats like boot malware or firmware rootkits often lay undetected while the compromised VM boots.

Shielded VMs come with security features to protect code in the cloud, which Google explains in a blog post released today by Nelly Porter, Google Cloud senior product manager, and Sergey Simakov, technical program manager for Google Cloud Security. They start with the firmware, which is based on UEFI 2.3.1 to replace legacy BIOS subsystems and enable UEFI Secure Boot.

The virtual Trusted Platform Module (vTPM) validates guest VM preboot integrity and generates and secures encryption keys. It allows the guest OS to create and protect keys and sensitive data. VTPM is required to launch Measured Boot, providing guest VM instances and cryptographically verifying the stack before the VM is permitted to access data stored in the cloud.

"The goal of the vTPM service is to provide guest VM instances with TPM functionality that is TPM2.0 compatible and FIPS 140-2 L1 certified," Porter and Simakov write. Google software engineer Josh Zimmerman further expands on vTPM security functionalities in a separate post.

vTPMs work like TPMs, which use platform configuration registers (PCRs) to log system states. Using the TPM's keys, the vTPM provides a "quote" of PCR values so remote servers can verify the state of a system. The TPM can protect sensitive data – for example, drive decryption keys, so they can be accessed only if a system state is valid.

Measured Boot, along with Secure Boot, helps defend Shielded VMs against boot- and kernel-level malware and rootkits. The two also ensure a user's VM launches a known firmware and kernel software stack. Secure Boot ensures the system runs legitimate software; Measured Boot verifies the integrity of the system software and VM boot process.

Users can access integrity reports for Shielded VMs via Stackdriver; they also can define their own policies and custom actions if the report indicates their VMs don't meet their security standards.

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
Microsoft, Mastercard Aim to Change Identity Management
Kelly Sheridan, Staff Editor, Dark Reading,  12/3/2018
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Starwood Breach Reaction Focuses on 4-Year Dwell
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/5/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: I guess this answers the question: who's watching the watchers?
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-19653
PUBLISHED: 2018-12-09
HashiCorp Consul 0.5.1 through 1.4.0 can use cleartext agent-to-agent RPC communication because the verify_outgoing setting is improperly documented. NOTE: the vendor has provided reconfiguration steps that do not require a software upgrade.
CVE-2018-19982
PUBLISHED: 2018-12-09
An issue was discovered on KT MC01507L Z-Wave S0 devices. It occurs because HPKP is not implemented. The communication architecture is APP > Server > Controller (HUB) > Node (products which are controlled by HUB). The prerequisite is that the attacker is on the same network as the target HU...
CVE-2018-19983
PUBLISHED: 2018-12-09
An issue was discovered on Sigma Design Z-Wave S0 through S2 devices. An attacker first prepares a Z-Wave frame-transmission program (e.g., Z-Wave PC Controller, OpenZWave, CC1110, etc.). Next, the attacker conducts a DoS attack against the Z-Wave S0 Security version product by continuously sending ...
CVE-2018-19980
PUBLISHED: 2018-12-08
Anker Nebula Capsule Pro NBUI_M1_V2.1.9 devices allow attackers to cause a denial of service (reboot of the underlying Android 7.1.2 operating system) via a crafted application that sends data to WifiService.
CVE-2018-19961
PUBLISHED: 2018-12-08
An issue was discovered in Xen through 4.11.x on AMD x86 platforms, possibly allowing guest OS users to gain host OS privileges because TLB flushes do not always occur after IOMMU mapping changes.