On Externalizing Cloud Trust

by Anton Chuvakin on August 26, 2020

Many of the cloud security and, in fact, cloud computing discussions ultimately distill to trust. Note that the concept of trust is much broader than cyber security, and even broader than a triad of security / privacy / compliance.

For example, trust may involve geopolitical matters focused on data residency and data sovereignty. At the same time, trust may even be about the emotional matters, something far removed from the digital domain of bits and bytes, going all the way to the entire society.

In a decade since the rise of cloud computing, a lot of research has been generated on the topic of cloud trust. Notably, today the very concept of “using public cloud” is inseparably connected to “trusting your cloud provider.”

One of the clear themes that emerged was that to be able to use trust cloud computing, you need to be able to trust it less.

A paradox? Not really!

Sponsorships Available

Imagine you have two choices:

Trust a cloud provider that has a lot of well-designed data security controls.
Trust a cloud provider that has a lot of well-designed data security controls and an ability to let the customer hold the encryption key for all their data (without any ability of the provider to see that key).

For sure, security, privacy and compliance controls contribute to trust towards cloud computing in general and your cloud provider in particular. However, it is still easier to trust the cloud if you can trust less.

Moreover, there is additional magic in this: I bet that simply knowing that your cloud provider is working in the direction of reducing the needed “leap of trust” will probably make you trust them more. This is true even if you don’t use all the trust-requirement-reducing features (such as Google Cloud External Key Manager (EKM) that allows a customer to keep their encryption keys on-premise and to never have that key come to Google or Confidential VMs that encrypts the sensitive data during processing [a good read on this topic]). Note that this logic also applies for cases where a public cloud environment is measurably more secure than an old on-premise environment — yet the on-premise feels more secure and hence more trusted.

This means that building technologies that allow organizations to benefit from cloud computing, while decreasing the amount of trust they need to place into the provider controls (both technical and procedural) is of huge importance.

However, such technologies are not only about the notional trust benefits — let’s briefly shift gears from trust to specific threat models.

Here I use an example list of threats that are addressed by a particular example of trust-requirement-reducing technology — our EKM. These are (in my opinion):

Accidental loss of encryption keys by the provider (however unlikely this is in real life); because the provider does not have the keys, it cannot lose them whether due to a bug, operational issue or any other reason.
Along the same line, a misconfiguration of native cloud security controls can, in theory, lead to key disclosure. Keeping they key off the cloud and in the hands of a cloud customer will reliably prevent this (naturally, at the cost of a risk of key being lost by a client).
A rogue provider employer scenario is also mitigated as said rogue employee cannot ever get access to the encryption key (this is also mitigated by a cloud HSM route) — admittedly, this is even more unlikely in real life.
Finally, if some entity requests that a provider surrender the keys to a particular client data, this becomes impossible because said keys are not in provider’s possession (here, I will leave this as an exercise to the reader to decide how unlikely that may be)

Operationally, protections such as our EKM make sense for a subset of sensitive data. For example, an organization may process sensitive data in the cloud, and only apply such trust reduction (or, better: “trust externalization”) for some of the data where their hesitation with trusting the cloud is the highest.

As we established, such trust-requirement-reducing technologies are not only about security threats. Their contribution to compliance is also significant: it applies to any requirement for a cloud customer to maintain the possession of encryption keys and also to any mandate to separate keys from data.

In fact, trust in the cloud is further enhanced by letting the customer have direct control over key access. Specifically, by retaining control of the keys, a cloud customer gains an ability to cut off cloud data processing by preventing key access. Again, to me, this is important for both actual threats and security/trust signalling. This reduces the need to trust and thus builds trust!

Furthermore, here is an interesting edge case: you may trust your cloud provider, but not the country where they are located. This is where trust again moves outside of the digital domain into a broader world. Our trust-requirement-reducing approach works here as well; after all, if nobody outside of a customer has the keys, nobody can compel any party (including a cloud provider) to reveal the keys and, hence, client data.

Now, a trick question: won’t there be a challenge of needing to trust that the provider build the trust-requirement-reducing controls correctly? Yes, sort of. However, I think there is a big difference between “just trust us” and “here is the specific technology we build to reduce trust; trust we built it correctly because of these reasons.” In other words, trust us because we let you trust us less.

Finally, some thoughts to keep this idea going:

Be aware that trust is much broader than security, compliance, and privacy.
Keep in mind that it is easier to trust a cloud provider that enables you to trust them less.
Remember, however, that specific threat models still matter — trust improvement alone probably won’t make people adopt new technologies.
Watch this fun Google Cloud Next OnAir presentation on this topic.
Finally, add “trust reduction” to your security arsenal: you can secure system components, sure, but you can also architect the system in such a way that you need to trust the components less. For the win!

On Externalizing Cloud Trust was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.