Discover our New & Exclusive Oracle Cloud Rewards Programme

New OCI Feature: Shielded Instances for Uncompromised Boot Security

Mike Dann Nov 22, 2021 2:43:16 PM

Contents

DSP-Explorer: What a Year for OCI - Part 1

Disaster Recovery Testing in Oracle Cloud

Model Deployment in OCI

Need the highest level of boot security for your OCI instances? Unable to migrate to cloud due to stringent security compliance requirements around server boot security? OCI Shielded instances may be for you.

Oracle has recently launched Shielded Instances. Shielded Instances are the same VM and bare-metal instances as before, just with an additional layer of security. They’re not for everyone nor are they appropriate for every cloud server. However, for those applications where you absolutely must have the highest level of security - for whatever reason whether regulatory, internal security policy, data sensitivity etc. - then Shielded Instances are worth consideration.

 

What are Shielded Instances?

Before delving into the details, Oracle’s documentation gives a good concise description of what Shielded Instances are:

Shielded instances harden the firmware security on bare metal hosts and virtual machines (VMs) to defend against malicious boot level software.

In simple terms, Shielded Instances are designed to protect the integrity of the instance boot process. Security of platforms - whether cloud-based or on-prem - must always be approached as multi-layered. No one thing will lead to bullet-proof security. It is the summation of various layers of security and security configuration working together that determines the overall security posture of a platform. Shielded instances are merely another security feature that, when deployed appropriately, can prevent (or at least identify) certain specific attack vectors - in this context to defend against malicious software that has been designed to interfere or in some cases replace, a server’s boot sequence. Returning to the notion of security layers, it is the responsibility of other security tools and best practices to defend against malicious software being injected into the boot process in the first place. However, if these tools and best practices fail in that defence, the next layer of protection is provided by Shielded Instances. Shielded Instances are designed to identify anomalies with the boot process before the instance fully boots, to then act accordingly. Malicious boot sequence software - typically called rootkits or bootkits, depending on where in the boot sequence they embed - is extremely difficult to detect once installed as it’s not uncommon for them, as part of the modified boot sequence, to disable, degrade or uninstall software whose role is to detect them.

Oracle Cloud Infrastructure Shielded Instances are available on either bare metal or VMs. On a security side note, irrespective of the new Shielded Instances offering, it’s worth remembering that OCI has offered bare-metal instances from inception, giving you sole access and control of that instance. If concerns exist with respect to running VMs on co-tenanted physical hosts and the phenomenon of virtual machine escape - essentially a bad actor exploiting a weakness to gain access to the underlying hypervisor of the host - the use of dedicated bare-metal instances eliminates those concerns.

 

The Fundamentals of a Shielded Instance

Shielded Instances harden the hardware firmware of the instance using a combination of the following three security features:

  • Secure Boot
  • Measured Boot
  • Trusted Platform Module (TPM)

Secure Boot is a Unified Extensible Firmware Interface (UEFI) feature. In simple terms, Secure Boot checks that the firmware is signed and that its signature is valid before boot. If boot components are found to be improperly signed, they are not allowed to run and therefore the boot sequence stops. Secure boot ensures that every component in the boot sequence has a valid (ie. correct) signature before being allowed to run. Secure boot is available on both bare-metal and VM instances. A server that fails Secure Boot during the boot process will not be allowed to complete boot and the instance will be unavailable. The principle being it’s better to ensure the instance is unavailable and therefore precluding the malicious code the opportunity to execute.

Measured Boot is complementary to Secure Boot and therefore both should be enabled if the highest level of security is required. When a Shielded Instance with Measured Boot enable is booted for the first time, measurements are taken of the boot components and stored as a baseline (or golden) measurement. Measurements taken for each subsequent boot are then compared against this golden measurement to identify a deviation in the boot sequence. Measured Boot is currently only available on VMs, although the same functionality can be achieved on bare-metal instances using third-party software. A server that encounters an anomaly during boot with Measured Boot enabled will still complete the boot sequence but will show a YELLOW or RED shield - depending on the nature of the failure (ie. warning or critical) - on the instance’s page within the OCI console. Unlike Secure Boot, as Measured Boot still completes the boot sequence after an anomaly is detected, and therefore results in an available instance – albeit one requiring review to understand the nature of the deviation.

The Trusted Platform Module (TPM) is a special-purpose security hardware chip used to store the boot measurements generated by Measured Boot. A bare-metal instance created with the TPM option can use it to store secrets.

Shielded Instances are appropriate for those instances where maximum security is required. It’s well known that security and convenience typically oppose each other. Shielded Instances are no exception as the security improvements they provide do come with some limitations and drawbacks. Not all are listed here, and further research is recommended, but some of the more notable are:
  • Measured Boot is not supported on bare-metal instances though as stated above, the same functionality can be achieved by using third-party software
  • Shielded instances do not support live migration or reboot migration
  • Bare-metal instances with TPM are not migratable as the hardware TPM is not migratable
  • Custom images (ie. custom boot volumes images) are not supported
  • Not all shapes are supported
  • Only Oracle Linux 7 and 8, Centos 7 and 8 and Ubuntu 18.04 and 20.04 images supported
  • You cannot change the shape of a Shielded Instance once created. The instance would need to be terminated and a new Shielded Instance created with the desired shape


Many of the limitations above will mean, as already stated, Shielded Instances are not appropriate for all instances. However, they are appropriate for those instances where the integrity of the boot process is deemed essential or maximum security is a must. Shielded Instances are yet another welcome security tool in the OCI security toolkit.

 

Creating a Shielded Instance 

Creating a Shielded Instance is as simple as selecting the required functionality - Secure Boot, Measured Boot, TPM - from the instance creation page as shown in the screenshot below. Or, of course, through other means of Instance Creation – such as APIs, CLIs, Terraform – that you might use to create any OCI resource.

OCI_Shielded_Instances

There’s a lot more detail related to Shielded Instances than is presented in this short blog. Further research, therefore, is recommended if Shielded Instances may be of interest to you. Please feel free to get in touch to organise a call with one of our technical consultants to discuss Shielded Instances further.

For more information, check out our Oracle Cloud Services and get in touch with an Oracle Cloud expert today.
Oracle Cloud Security OCI

DSP-Explorer: What a Year for OCI - Part 1

Disaster Recovery Testing in Oracle Cloud

Model Deployment in OCI
Previous

Disaster Recovery Testing in Oracle Cloud
Next

DSP-Explorer: What a Year for OCI - Part 1

Leave a Comment