Contributed by Jethro Beekman, Fortanix
As more organizations continue to migrate to the cloud, concerns remain about security of the infrastructure backing the cloud and privacy of their data. For decades, businesses have been trying to run software with hardened, more secure architectures. Such architectures modified for today’s cloud are generally known as shielded compute, confidential compute, enclave-based cloud, and protected module architectures (PMA). Various security technologies offering these approaches are currently available from companies such as Intel (SGX), AMD (SKINIT, SME and SEV), ARM (TrustZone) and Microsoft (VBS). When deciding which approach is best for your organization, consider these key principals for securely migrating data and systems to the cloud.
#1: Lower your TCB (Trusted Computing Base)
Whichever approach you choose, organizations should look for an architecture that implements complete mediation, enables least privilege, and can significantly reduce the trusted computing base (TCB). Complete mediation ensures that all access paths are checked. For example, a bank can have a state-of-the art biometric security system at the front door, but that’s not going to stop anyone from climbing through the basement window. Least privilege is about compartmentalization: Making sure that once a user is inside, he or she is allowed to only see or do certain things in accordance to identity and access policies, such as interact with the bank teller, but the user cannot gain access to the bank’s vault.
Reducing the TCB means less opportunities to do things wrong. Keeping with the bank analogy, it’s easier to secure a small fortified building than it is to secure an entire campus. As it turns out, most of the commercially available security technologies simply don’t meet the three properties of complete mediation, least privilege, and reduced TCB.
#2: Confidentiality is hard, but integrity is much harder
The security properties of complete mediation, least privilege, and reduced TCB can be partially attained using cryptography. However, an organization can’t build a secure system relying only on confidentiality (encryption). They have to also use integrity protection. This is a well-known principle in cryptographic engineering. Not using integrity protection can be considered a failure in complete mediation. That is because without it not only can someone tamper with data outside the security boundary, but the tampered data is allowed right back in during decryption. This often leads to unfortunate results. For example, it’s the lack of integrity protection that has left AMD SME/SEV vulnerable to attack, as described in two papers from Cornell University last month and 2016.
#3: Protect workloads from privileged threats
Current-day computer systems generally have a strictly hierarchical privilege model, which can’t properly enable least-privileged designs. ARM TrustZone, for example, introduces a special secure mode on the processor, but for the most part it is just a more privileged mode of the processor. This means that all software running in secure mode has blanket access to all other software and data running in both secure and non-secure mode. The best scenario is to have separate programs responsible for their own data.
Modern computing infrastructure is extremely complex. For example, consider the boot process of a typical computer. To get to a running state, you need to go through the BIOS, the bootloader, possibly the hypervisor, the kernel, and the graphical shell. And that’s just for the CPU. There might be other components that also have privileged access to system components, such as an embedded processor (Intel ME or AMD PSP), or a baseboard management controller (BMC). Technologies that require security of a large chunk of the platform and boot chain such as Intel TXT, AMD SKINIT, and Microsoft VBS can’t practically be used in a secure way because the TCB is so large. This is especially true if organizations don’t want to trust the platform owner, such as in the cloud.
The best solution is one that offers complete mediation by implementing integrity-protected encryption and isolation directly at the processor level. This also reduces the TCB to just the processor and the application. And it’s that same isolation that allows an organization to split up its application achieving least privilege.
Getting to the secure cloud
Organizations looking to secure sensitive workloads in the cloud need an end-to-end approach that provides security from the hardware to the cloud. Solutions that enable security controls to be embedded in the application are desirable, but the controls need to be rooted in hardware-based security. The solution must provide complete isolation of the application from other applications on the same system, and even from the operating system or hypervisor, protecting the application against root users and physical attacks. The application’s memory and data in use must be protected using encryption to thwart unauthorized access. The technology should enable applications to extend the runtime encryption easily to support end-to-end encryption for persistent data and data in transit. In addition to confidentiality, the solution must also deliver integrity protection. The solution should enable proof of secure execution by being able to attest that the application is running securely.
The use of hardware-based security controls that run within an application has the potential to deliver deterministic security that automatically scales as the application scales in the cloud. Finally, any solution selected must balance security and ease of use. The solution must be easy for application developers and security architects to adopt without a significant learning curve, and ideally be compatible with millions of existing cloud and data center applications. All this combined is the best way to securely migrate to the cloud.
Disclaimer: The opinions expressed within this article are the personal opinions of the author. The facts and opinions appearing in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.
