There are many different attack scenarios in cloud computing. Each layer in the cloud stack has the potential to expose a ruinous vulnerability. This includes the hosted applications, the virtualization environments, server hardware and other infrastructure necessary to support a cloud solution. These are the things that keep security-minded cloud service providers up at night.

To help alleviate some of these concerns, cloud service providers should be demanding that their vendors deliver best-in-class security solutions for each layer in their system. The obvious question, however, is how does one know if the vendor’s security story is good enough? This article deals with some of the issues one can raise with their vendors to better protect your infrastructure from attacks.

Evaluate Where You are Vulnerable

Since early 2018, new server-class vulnerabilities have been popping up in the form of CPU microarchitectural attacks.  These attacks include Spectre, Meltdown, Foreshadow, RIDL, Fallout and Zombieload. As CPU manufacturers try to combat the competing needs of high performance coupled with security, they are likely to continue to struggle.

Mike Hamburg, a member of the Spectre team and a Rambus security researcher, is quoted as follows, “…beyond short-term solutions such as patching, the semiconductor industry should seriously consider designing chips that run sensitive cryptographic functions in a physically separate secure core, silo-ed away from the CPU. This design approach will go a long way in helping to prevent vulnerabilities that can be exploited by Meltdown and Spectre.”

The quote above is a call for CPU vendors to begin to look for different means to protect security critical assets from CPU-based microarchitectural attacks. The current mix of defects all center around CPU designs intended to increase processing efficiency for demanding workloads. Current fixes that mitigate some of these flaws reduce processing efficiency. What are CPU vendors doing to fix these issues, while maintaining the processing efficiency required for hosting demanding cloud services?

Beyond the server CPUs that run the virtualized environments for hosting cloud applications, the servers have many other CPUs in their subsystems that are executing firmware. These CPUs can be in the hard disk controller, network controller, base management controller and other server components. How is one to be sure that the proper firmware is executing on each of these subsystems? How does one know whether these subsystems are leaking system secrets to attackers?

Beyond server-level security, cloud platform providers should be asking the vendors of other network infrastructure what they are doing to secure their hardware. Like the many server subsystems, network appliances and other equipment have their own CPUs and firmware. Again, it is up to cloud service providers to ask the right questions of their vendors to better understand the security risks for their infrastructure.

Hardware Root of Trust  

One critical solution that cloud service providers should be asking about is the inclusion of hardware roots of trust in their equipment. A properly designed hardware root of trust can be the central component to solve many of the issues described earlier in this article.

The National Institute of Standards and Technology (NIST) of the U. S. Department of Commerce defines a hardware root of trust as: “. . . many roots of trust are implemented in hardware so that malware cannot tamper with the functions they provide. Roots of trust provide a firm foundation from which to build security and trust.”

Hardware roots of trust can be used in many different cloud infrastructure security applications. For example, a hardware roots of trust can be used to securely boot firmware of components in a server, network equipment and other parts of your infrastructure. The same hardware roots of trust can also be used to assist in secure firmware updates for the same components.

Looking beyond firmware boot and update security, hardware roots of trust can be used for secure key management, cryptographic algorithm acceleration, cryptographic protocol support and many other applications. If a hardware root of trust is programmable, such that it can support many different applications, increases the value of your investment.  

Modern, state-of-the-art hardware roots of trust have a CPU that can execute applications to support its platform. These hardware roots of trust must also support mechanisms for isolating security assets between each of the applications. For example, one likely does not want their cryptographic accelerator application to have access to the secure firmware update assets and vice versa.

Going back to Mike Hamburg’s quote above, one can also use hardware roots of trust to help with solving the microarchitectural attacks plaguing the industry today. Given the proper software ecosystem support, one can offload critical security functionality to a hardware root of trust. A root of trust that has been designed from the bottom with security in mind should not be susceptible to similar attacks as the high-level CPU system. Secure keys managed and used inside the root of trust would no longer be vulnerable to exposure.

Conclusion

Cloud service providers have a lot on their minds when it comes to securing their solution. To alleviate some of these concerns, they must demand the latest security solutions from their vendors. Each vendor of each layer of the cloud platform solution must be able to provide answers to how they are staying on the cutting edge of security technology.

These security solutions should include using hardware roots of trust. Beyond simply including hardware roots of trust in their products, cloud equipment vendors must also be able to explain how they are used. They should also be able to explain how the cloud service providers can take advantage of the hardware roots of trust themselves. 

After collecting the answers from their vendors regarding how their vendors are or are not using hardware roots of trust, cloud service providers can better assess their security risks. They can then put a plan in motion to move to new vendors who meet their security requirements.