Google CloudOverview
To defend against advanced threats and ensure that the boot loader and firmware on your VMs are signed and untampered, it is recommended that Compute instances are launched with Shielded VM enabled.
Rationale
Shielded VMs are virtual machines (VMs) on Google Cloud Platform hardened by a set of security controls that help defend against rootkits and bootkits.
Shielded VM offers verifiable integrity of your Compute Engine VM instances, so you can be confident your instances haven't been compromised by boot- or kernel-level malware or rootkits. Shielded VM's verifiable integrity is achieved through the use of Secure Boot, virtual trusted platform module (vTPM)-enabled Measured Boot, and integrity monitoring.
Shielded VM instances run firmware which is signed and verified using Google's Certificate Authority, ensuring that the instance's firmware is unmodified and establishing the root of trust for Secure Boot.
Integrity monitoring helps you understand and make decisions about the state of your VM instances and the Shielded VM vTPM enables Measured Boot by performing the measurements needed to create a known good boot baseline, called the integrity policy baseline. The integrity policy baseline is used for comparison with measurements from subsequent VM boots to determine if anything has changed.
Secure Boot helps ensure that the system only runs authentic software by verifying the digital signature of all boot components, and halting the boot process if signature verification fails.
Remediation guidance
From Google Cloud Console
- Go to the
VM instancespage by visiting: https://console.cloud.google.com/compute/instances - Click on each VM instance name to go to its details page
- Click
STOPand then clickEDIT - Under the section
Shielded VM, selectTurn on vTPMandTurn on Integrity Monitoring - Optionally, if you do not use any custom or unsigned drivers on the instance, also select
Turn on Secure Boot - Click
Saveand then clickSTART
Using Google Cloud CLI
- Stop the instance:
gcloud compute instances stop <instanceName>
- Update the instance:
gcloud compute instances update <instanceName> --shielded-vtpm --shieldedvm-integrity-monitoring
- Optionally, if you do not use any custom or unsigned drivers on the instance, also turn on secure boot.
gcloud compute instances update <instanceName> --shielded-vm-secure-boot
- Restart the instance:
gcloud compute instances start <instanceName>
Prevention
You can ensure that all new VMs will be created with Shielded VM enabled by setting up an Organization Policy to for Shielded VM at https://console.cloud.google.com/iamadmin/orgpolicies/compute-requireShieldedVm. Learn more at: https://cloud.google.com/security/shielded-cloud/shielded-vm#organization-policyconstraint.
Default Value
By default, Compute Instances do not have Shielded VM enabled.
References
- https://cloud.google.com/compute/docs/instances/modifying-shielded-vm
- https://cloud.google.com/shielded-vm
- https://cloud.google.com/security/shielded-cloud/shielded-vm#organization-policy-constraint
Additional information
If you do use custom or unsigned drivers on the instance, enabling Secure Boot will cause the machine to no longer boot. Turn on Secure Boot only on instances that have been verified to not have any custom drivers installed.
Multiple Remediation Paths
Google Cloud
SERVICE-WIDE (RECOMMENDED when many resources are affected): Enforce Organization Policies at org/folder level so new resources inherit secure defaults.
gcloud org-policies set-policy policy.yaml
ASSET-LEVEL: Use the product-specific remediation steps above for only the impacted project/resources.
PREVENTIVE: Use org policy constraints/custom constraints and enforce checks in deployment pipelines.
References for Service-Wide Patterns
- GCP Organization Policy overview: https://cloud.google.com/resource-manager/docs/organization-policy/overview
- GCP Organization policy constraints catalog: https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- gcloud org-policies: https://cloud.google.com/sdk/gcloud/reference/org-policies
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- Google Cloud: apply organization policy constraints at org/folder scope.
gcloud org-policies set-policy policy.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
GCP VMs with security features disabled
Connectors
Covered asset types
Expected check: eq []
{
vms(
where: {
OR: [
{ shieldedInstanceConfigEnableVtpm: false }
{ shieldedInstanceConfigEnableSecureBoot: false }
{ shieldedInstanceConfigEnableIntegrityMonitoring: false }
]
}
) {
...AssetFragment
}
}
