SBN

Usage Scenarios for Externalized Trust

As we discussed in “The Cloud trust paradox: To trust cloud computing more, you need the ability to trust it less”, there are situations where the encryption key really does belong off the cloud and so trust is externalized. While we argue that these are rarer than some assume, they absolutely do exist. Moreover, when these situations materialize, the data in question or the problem being solved is typically hugely important for an organization.

Here are three critical scenarios where keeping the keys off the cloud may in fact be truly necessary [and possible with Hold Your Own Key (HYOK) approach implemented via Google EKM].

Scenario 1 The Last Data to Go Up

As organizations migrate data processing workloads to the cloud, there usually is this pool of data that just cannot go. It may be the most sensitive, strictly regulated or the one with the toughest internal security control requirements.

This means that risk, compliance or policy reasons make it difficult if not impossible to send this data set to the public cloud provider for storage or processing. This use case often applies to a large organization that is heavily regulated (financial, healthcare and manufacturing come to mind). It may be the data about specific “priority” patients or data related to financial transactions of a specific kind.

However, the organization may be willing to migrate this data set to the cloud as long as it is encrypted and they have sole possession of the encryption keys. Thus, a specific decision to migrate may be made involving a combination of risk, trust, as well as auditor input. Or, customer key possession may be justified by customer interpretation of specific compliance mandates.

Examples of such highly sensitive data vary by industry and even by company. One organization may want to keep the keys that decrypt the credit card data, while others deal with citizen data, banking data or other sensitive personal information. Another organization may be driven by their interpretation of PCI DSS and internal requirements to maintain control of their own master keys in FIPS 140–2 level 3 HSMs that they own and operate for their cloud workloads.

Now, some of you may say “but we have the data that really should not go to the cloud.” I don’t want to use an analogy of horses vs cars (“but we have some people who prefer to ride a horse and will never use a car” may have worked in the 1920s), but the acceptance that digital transformation projects require the agility of the cloud powered by cloud practices and technologies is there to stay.

Scenario 2 Regional Regulations and Concerns

As cloud computing evolves, regional requirements start to play a larger role in how organizations migrate to the cloud and operate workloads in public cloud. This scenario focuses on a situation where an organization outside of the US wants to use a US cloud (because, frankly, there is no other kind), but is not comfortable with the provider having access to encryption keys for all data. Some of them may be equally uncomfortable with keys stored in any cryptographic device (such as an HSM) under logical or physical control of the cloud provider. They reasonably conclude that such an approach is not really HYOK.

This may be due to trust issues with the provider, regulations they are subject to, their government or all of the above. Furthermore, regulators in Europe, Japan, India, Brazil and other countries are creating or strengthening mandates for keeping unencrypted data and/or encryption keys within their boundaries. However, preliminary data indicates that some may accept the models where the encryption keys are in a sole possession of a customer and located in their country, and hence off the cloud provider premises (while the encrypted data is in the US)

As Thomas Kurian said here, “data sovereignty provides customers with a mechanism to prevent the provider from accessing their data, approving access only for specific provider behaviors that customers think are necessary. Examples of customer controls provided by Google Cloud include storing and managing encryption keys outside the cloud, giving customers the power to only grant access to these keys based on detailed access justifications, and protecting data-in-use. With these capabilities, the customer is the ultimate arbiter of access to their data. “

Examples may include specific industry mandates (such as TISAX in Europe) that either state or imply that the cloud provider cannot have access to data under any circumstances, that may necessitate not having any way for them to access the encryption keys.

Another variation is the desire to have the keys for each country specific data set in the respective country under the control of that country’s personnel. This may apply to banking data and will necessitate the encryption keys for each data set being stored in each country. A hypothetical example may be a bank that insists that all their encryption keys are stored under one mountain in Switzerland …

Yet another example covers the requirements (whether regulatory or internal) to have complete knowledge and control over the administrators of the keys, and a local audit log of all key access activity.

Scenario 3 Centralized Encryption Key Control

With this use case there is no esoteric threats to discuss or obscure audit requirements to handle. The focus here is on operational efficiency. As Gartner recently noted, the need to reduce the number of key management tools is a strong motivation for this.

It may sound like a cliche, but complexity is very much the enemy of security. Multiple presumably “centralized” systems for any task — be it log management or encryption key management — add to complexity burden and introduce new points for security to break and fall through the cracks.

In light of this, a desire to use one system for a majority of encryption keys, cloud or not, is understandable. Additional benefits may stem from using the same key management vendor as an auxiliary access control and policy point. A common set of keys reduces complexity and a properly implemented system with adequate security and redundancy outweighs the need to have multiple systems.

Another variant of this is a motivation to retain control over data processing by means of controlling the encryption key access. After all, if a client can push the button and instantly cut off the cloud provider from key access, the data cannot possibly be accessed or stolen by anybody else. Thus, centralization of their key management gives the cloud user a central location to enforce policies around access to keys and hence access to data-at-rest.

Conclusion

These scenarios truly call for encryption keys being both physically away from the cloud provider and away from their administrative control. This means that a customer-managed HSM device at the CSP location won’t do here.


Usage Scenarios for Externalized Trust was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.


*** This is a Security Bloggers Network syndicated blog from Stories by Anton Chuvakin on Medium authored by Anton Chuvakin. Read the original post at: https://medium.com/anton-on-security/usage-scenarios-for-externalized-trust-34e1fa8a6ad1?source=rss-11065c9e943e------2