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
'PowerSnitch' Hacks Androids via Power Banks
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/8/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: New camera 2FA closed loop!
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-20050
PUBLISHED: 2018-12-10
Mishandling of an empty string on the Jooan JA-Q1H Wi-Fi camera with firmware 21.0.0.91 allows remote attackers to cause a denial of service (crash and reboot) via the ONVIF GetStreamUri method and GetVideoEncoderConfigurationOptions method.
CVE-2018-20051
PUBLISHED: 2018-12-10
Mishandling of '>' on the Jooan JA-Q1H Wi-Fi camera with firmware 21.0.0.91 allows remote attackers to cause a denial of service (crash and reboot) via certain ONVIF methods such as CreateUsers, SetImagingSettings, GetStreamUri, and so on.
CVE-2018-20029
PUBLISHED: 2018-12-10
The nxfs.sys driver in the DokanFS library 0.6.0 in NoMachine before 6.4.6 on Windows 10 allows local users to cause a denial of service (BSOD) because uninitialized memory can be read.
CVE-2018-1279
PUBLISHED: 2018-12-10
Pivotal RabbitMQ for PCF, all versions, uses a deterministically generated cookie that is shared between all machines when configured in a multi-tenant cluster. A remote attacker who can gain information about the network topology can guess this cookie and, if they have access to the right ports on ...
CVE-2018-15800
PUBLISHED: 2018-12-10
Cloud Foundry Bits Service, versions prior to 2.18.0, includes an information disclosure vulnerability. A remote malicious user may execute a timing attack to brute-force the signing key, allowing them complete read and write access to the the Bits Service storage.