Confidential Compute + Data Policy: The Reese’s™ Peanut Butter Cups Of Real Zero Trust

Before we get into The Good Candy—confidential compute + data policy, we need to talk about what I consider to be The Bad Candy—the inferior substitute, “fake” Zero Trust.

“Fake” Zero Trust - The Peeps™ Of Security Solutions

Hopefully at this point the hype around “fake Zero Trust” has died down—and by “fake,” I mean “Zero-Trust” solutions that are rebadged perimeter defense systems: Perimeter-centric, not data-centric, security solutions. Solutions that are designed to guarantee security within a perimeter of trust, but don’t account for how data flows over that perimeter. Solutions that can only make guarantees about data handling for data within their own system. Solutions that look good at first, but are just the same, not-particularly-compelling marshmallow underneath.

True Zero Trust security is, and must be, data-centric security.

Policy that flows with the data—not simply policy that only applies to data in transit or at rest within a vendor’s “secure perimeter.”

This isn’t to say that secure perimeters aren’t useful. They’re exceptionally useful when data is still and at rest, and we need to do things with it. They are used in the context of a real Zero-Trust system, as we will see—but on their own, they can’t be Zero Trust.

Confidential Compute: The Peanut Butter

One of the new pillars upon which data-centric Zero-Trust security is being built is confidential compute. Confidential compute allows encryption, decryption, and other sensitive operations involving at-rest data to take place in a hardware enclave where it can be cryptographically proven that:

• Cloud providers hosting and running the hardware cannot touch the data or the operation
• Cloud operators cannot touch the data or the operation
• Other processes and machines sitting right next to it can’t touch the data or the operation
  
  

There’s a lot of exciting and critical work happening in the confidential compute space, including:

• Google Cloud’s new Confidential Space
• Edgeless Systems’ MarbleRun control plane for confidential computing
• The AWS Nitro System

Confidential compute is a massively exciting development because it gives us the ability to perform sensitive computations (decryption, ETL, processing, data anonymization) in an encrypted memory space, or in some limited cases, within the hardware TPM module itself.

By themselves, these solutions are simply a part of the puzzle, though—especially if they are cloud-provider-centric (or even worse, hardware-specific), as virtually all of them are. They are just another perimeter, and taken in isolation, they can never offer a complete solution, because at best they cannot account for data flowing in and out of their own cloud perimeter, and at worst they cannot account for data flowing in and out of the confidential compute perimeter within their own clouds.

Data is secure as long as it is in the confidential compute enclave. Data is secure as long as it is residing or being transported within the cloud provider’s systems, at the very most (though again, none of the major cloud providers can currently guarantee this best-case scenario, especially not in multi-party confidential compute flows).

And that’s simply not enough for a true, end-to-end Zero Trust solution—because useful data moves. Useful data flows. Data does not respect boundaries or perimeters. Getting data to the secure compute enclave, getting it back out, sharing outputs with people, cryptographically tying data policy to the confidential compute architecture—none of that is solved in any meaningful way by any of the big cloud providers, or by any smaller security vendors, or by any form of confidential compute.

What’s more, it’s a truism that no large cloud provider will ever offer a workable solution for this problem, because cloud providers simply have no interest or incentive to protect data outside of their cloud—because of what their business model is, they will only ever offer a larger perimeter—that is, “fake,” or perimeter-centric, Zero Trust. Data coming from outside their cloud? They can’t help you. Data leaving their cloud? They can’t help you. Even within their own clouds the guarantees they can provide are extremely limited, because none of them have strong, cryptographically bound data policy controls, and the few attempts at this don’t fit cleanly or easily within the RBAC-centric IAM permissioning models every cloud provider has built their cloud stacks around. “You’re OK within these walls, but we can’t help you with anything that leaks out, or that anyone takes out, and we can’t help you share it securely with people outside of these walls.” It’s not a technical hurdle, it’s simply not possible within the framework of their business model, and likely never will be.

Data centric security requires confidential compute as a substrate. Confidential compute is the salty, substantial, peanutty middle, but confidential compute on its own is not, and will never be, data security (in the same way that peanut butter on its own is not and will not ever be candy, sorry butter nutters). None of the Big Three cloud providers can or will solve this problem on their own.

Cryptographically Bound Data Policy: The Chocolate

Confidential compute is awesome, but getting the data to the confidential compute space and getting it back out is something confidential compute will never solve for. Confidential compute on its own is still fundamentally perimeter-based security, and it can’t help us with anything outside that perimeter—even though within the confidential compute perimeter we can have exceptionally strong cryptographic guarantees.

This is where having cryptographically bound data policy is critical to actually building a useful solution on top of confidential compute: It solves for the perimeter problem. When data is cryptographically bound to a policy that travels with the data—dictating what, when, and where that policy can be accessed—ingesting and emitting that data in a confidential compute space becomes significantly more powerful, more practically secure, and more useful.

It gives us the ability to:

• Require that data only be accessed within specific confidential compute environments.
• Know that data entering confidential compute environments is actually intended for that environment.
• In a true multiparty confidential compute space, give data contributors absolute control and cryptographic guarantees over each individual piece of data: where it can be accessed, what it can be combined with, and what happens to it after it necessarily and inevitably leaves the secure compute perimeter.

Without cryptographically bound data policy that moves with the data, as the data flows through the system, and is tightly integrated with confidential compute policy and cryptographic guarantees, the usefulness of confidential compute is severely limited.

We need the peanut butter (confidential compute) and the chocolate (verifiable, cryptographically bound data policy) together to get a good peanut butter cup. Peanut butter without the chocolate is good. Chocolate without peanut butter is good. To get something great though, we need to combine them: They each bring important elements, but when working together they create something special.

Having Our Candy And Eating It, Too: The Hard Problem Is Data Policy