The pace at which new confidential computing solutions are penetrating enterprise security architectures and data protection strategies appears to be catching security leaders off balance. COVID-19-accelerated digital transformation saw years’ worth of cloud migration, “zero trust” management and online collaboration tool rollouts squeezed into a few short months. Solutions engineering and security teams that thought they’d have a couple years to learn and master the next set of security- and privacy-preserving technologies are suddenly playing catch-up in the newly “cloudified” enterprise.
Having already mastered and commodified “data-at-rest” and “data-in-transit” security, security leaders are under pressure to support companies’ adoption of confidential computing technologies and newly enabled trusted execution enclave (TEE) services. If 2020 represented a step function for digital transformation and cloud adoption for businesses, 2021 will be the year of rapid, measurable “data-in-use” security and privacy.
As the list of new and pending TEE-enabled products and services from major public cloud providers grows, where should CISOs and security architects begin? For most organizations, the two most influential confidential computing building blocks will be enclave attestation and enclave-enabled relational databases.
Whether the organization is planning on utilizing in-house or cloud computing builds atop Intel SGX or AMD SEV chip architectures (or Arm, NVIDA, etc. in the future), attestation lays at the heart of confidential computing trust. Enclave provisioning and trust will quickly become as fundamental to enterprise security as identity management, certificate management and key management.
Enclave attestation services are designed to verify and validate that the confidential computing workload is provisioned and executed securely in a TEE environment. Remote attestation services will necessarily vary in environmental specifics, but they generally validate the integrity — the root of trust, hardware status, firmware status, security patch status, etc. — of the TEE (hardware or virtualized) before releasing sensitive data into the enclave. It is therefore the attestation service’s responsibility to cryptographically ensure that the underlying hardware and firmware is not in a vulnerable state before use, that the workload assigned to the enclave is transferred securely and, upon execution, that the enclave remains secure and the workload’s computing functions and output were not tampered with in any way. In essence, confidential computing attestation tells you if the results that your code generated within the TEE are trustworthy.
It won’t be long before CISSP study materials include attestation mechanics with an “Alice and Bob” explanation, like those used to teach data flows that constitute asymmetric cryptography and key exchange mechanics. For most InfoSec professionals, a basic understanding of enclave attestation will be adequate for traffic routing and troubleshooting. A deeper understanding will be required for architects and DevOps teams tasked with deploying and trusting new confidential compute workloads.
In parallel to incorporating enclave attestation service design into new business application architectures, security and privacy leaders will need to leverage enclave-enabled relational databases — especially if they’re to meet toughening regulatory requirements linked to customer data privacy.
In the database world, balancing privacy and “data-at-rest” encryption with data utility and business application performance has been a delicate, often compromising, affair. Encrypted column data (for example, customer names, addresses and blood types) logically makes it more difficult to perform searches and match records. The use of deterministic encryption techniques (for instance, encryption that always generates the same encrypted value for any plain text value) is vulnerable to some predictive attack vectors. However, randomized encryption techniques are more secure but make most common query types impossible.
To protect sensitive data from malware and high privileged unauthorized users of the database server, traditional non-TEE data encryption processes protect the data by encrypting it on the client side. This means disallowing the data or corresponding cryptographic keys from appearing in plaintext inside the database engine. When deterministic encryption is used, the only operations the database engine can perform are equity comparisons. All other operations, including cryptographic operations (initial data encryption or key rotation) or rich computations (for example, pattern matching), are not supported inside the database. Users need to move their data outside the database to perform these operations on the client side. These actions are completed as a secure software agent to transport encrypted column data to a remote host or system to decrypt and perform query actions upon the data, then re-encrypt data that needs to be written back to the protected column.
For operations teams tasked with regulatory data discovery, labeling and protection throughout the enterprise, the mechanics of securing client agents and shuffling encrypted data between systems —temporarily duplicating data in the process — is inefficient and burdensome. TEE-enabled database services ensure the encrypted data remains within the system, allowing computations on plaintext data inside the secure enclave with no way to view data or code inside the enclave from the outside (even with a debugger). In addition, rich computations, such as operations on encrypted columns, are possible, and cryptographic operations on sensitive data, like initial data encryption or rotating a column encryption key, are performed within the enclave and do not require moving the data outside the database.
As confidential compute services become ubiquitous, enclave attestation and enclave-enabled relational database technologies will be fundamental building blocks for post-COVID-19 business application design and delivery. CISOs and their security teams need to quickly master these technologies if they’re to successfully partner with in-house development teams and secure “data-in-use.”
-- Gunter Ollmann
First Published: SecurityWeek - December 22, 2020
