[MUSIC PLAYING]
JASIKA BAWA: Welcome to the "Google Cloud Security
Showcase," a special web series where
we'll focus on security use cases
that customers can solve with Google Cloud.
My name is Jasika, and I'm a product manager
at Google Cloud.
Today, we'll be walking through one of the top questions we
get from customers--
how can I protect my GCP virtual machines
from rootkits and bootkits?
Shielded VMs are hardened Compute Engine virtual machines
that offer protection from persistent threats
like rootkits and bootkits.
This is possible using the platform security features
offered by Shielded VM--
a virtual Trusted Platform Module, or TPM,
secure and measured boot on top of UEFI firmware,
and integrity monitoring.
Shielded VM is the default VM option across Compute Engine
and is available to all customers
at no additional charge, so it's now easier than ever
to spin one up.
Start at Compute Engine, VM Instances
to create a new instance.
Give your instance a name, and then
head on over to change the boot disk
to the OS image of your choice.
Since Shielded VM is now the default for most modern OSes,
at this point, all you have to do is pick an OS and version.
You can confirm that this OS supports
Shielded VM features based on this helpful description.
Finally, hit the Create button, and you're good to go.
Next, we're going to take a closer look
at integrity monitoring, which can help you understand
and make decisions about the low-level integrity
state of your Shielded VM instances.
Integrity monitoring relies on the measurements created
by measured boot, which use Platform Configuration
Registers, or PCRs, to store information
about each boot sequence.
Integrity monitoring results are written out
to Stackdriver logging.
Here, you can filter to just show Shielded VM integrity
logs.
As you can see, there are both early as well as late boot
events available here.
Early boot is the boot sequence from the start of the UEFI
firmware until it passes control to the bootloader.
And late boot is the boot sequence from the bootloader
until it passes control to the operating system kernel.
Look into the earlyBootReportEvent
and expand its JSON payload.
Since the most recent boot sequence
matches that of the integrity baseline, a known
good or assumed healthy boot sequence,
you can see that the integrity validation has passed.
Note that you can also use integrity monitoring
to establish the provenance of the instance you're looking at.
For example, under resource, you have a record
of the instance ID, project ID, and zone
that this instance lives in.
So far, you've seen what a successful integrity
validation looks like.
On the other hand, if either the early or late boot
parts of the most recent boot sequence
don't match the baseline for the VM,
an integrity validation failure would be expected.
To illustrate this, first, SSH into the VM.
Next, tamper with the VM's bootloader--
the first program that runs when a machine starts--
by changing a single string in the GRUB bootloader on disk.
Note that this is a very simple proof of concept,
but in practice, an attacker could instead
modify the bootloader to load a malicious kernel,
gain persistence on the machine, or perform other behaviors
characteristic of rootkits and bootkits.
Now that this VM has been tampered with,
you can check back with integrity monitoring
to see what that looks like.
As you may recall, late boot is the boot sequence
from the bootloader until it passes control
to the OS kernel.
Since the bootloader for this VM has been modified,
it's expected that the most recent late boot sequence won't
match the integrity baseline for the VM, which
should result in an integrity validation failure.
Sure enough, you can see this failure here
in Stackdriver, specifically caused
due to a discrepancy in PCR 4, which measures the bootloader.
Remember that you can always create custom actions
based on what you see here.
For example, you can use Pub/Sub and Cloud Functions
to create automation to terminate Shielded VM instances
that fail integrity validation.
So now, we've seen how integrity monitoring can
help catch anomalous changes, while still
allowing the operating system to boot successfully.
This offers the flexibility to investigate the integrity
failure and respond in a way that makes the most
sense for your workload.
However, for the ideal security posture,
you wouldn't want the VM to boot at all in this potentially
compromised state.
This is where secure boot, another feature of Shielded VM,
comes in.
Secure Boot helps ensure that the system only
runs authentic software by verifying
the signature of all boot components
and halting the boot process if signature verification fails.
As shown here, you can enable secure boot
on an existing Shielded VM as long
as the VM has been stopped.
You can also turn on secure boot at the time of VM creation
using the console, G Cloud, or API.
Note that secure boot is not enabled by default
because unsigned drivers and other low-level software
might not be compatible with it.
If appropriate for your workloads though,
Google recommends enabling secure boot.
With that important change made, let's go ahead
and start the VM again.
Now you can verify that secure boot indeed
prevents this VM with a tampered bootloader from booting.
You can do so using the serial console, built
to troubleshoot inaccessible instances.
Here, we can see that secure boot detected the tampering
and prevented the instance from booting.
That was a quick overview on how Shielded VMs can
help protect your workloads from threats
like rootkits and bootkits.
Thank you for tuning in.
Please visit cloud.google.com/security
for more content from Google Cloud experts.
[MUSIC PLAYING]