CLOUD DATA SECURITY

Recommendations for Implementing the Right Cloud Crypto and Key Management Solution

Introduction

Enterprises across industry segments are moving IT workloads and functions to the cloud,
frequently ahead of any strategy or consistent capability to secure sensitive data. The advantages
of cloud migration, such as scale, agility, and consumption-based pricing, are compelling and
seem to outweigh the risks in the short term.

Most enterprise IT today is hybrid, with some workloads in the cloud and some hosted within the
enterprise datacenter. Many are adopting a “cloud-first” or “cloud-only” approach for all new IT
functions and business. Due to a combination of decentralized IT functions, frequent mergers
and acquisitions, and shadow IT, most enterprises are multi-cloud, leveraging more than one
cloud service provider (CSP).

Data security is rarely the first consideration for the selection of a CSP. The emergence of strict
new data privacy regulations, such as GDPR and CCPA, is driving the need for CISOs to more
effectively address data protection and data governance in complex and geographically-diverse
hybrid IT ecosystems. The terms pseudonymization and anonymization are now common in the
context of these privacy regulations when it comes to data protection and privacy. While
pseudonymization of data still allows for some form of re-identification (even indirect and
remote), while anonymization of data cannot be re-identified. CISOs look to the CSPs for data
security solutions to address these privacy requirements but struggle with the confusing array of
security models and services they offer.

CSPs offer native key management, encryption, and Hardware Security Module (HSM) services.
These security services have typically been added as a layer on top of their existing stacks;
after-thoughts from a late recognition of their customers’ increasing data security concerns, and
are not enterprise-grade. As most enterprises are also multi-cloud, the challenges inherent in CSP
security offerings include deficiencies in uniformity, homogeneity, coverage, customer control
and ownership, functionality, scalability, performance, visibility, and more. On top of these, there
are broader challenges with key management, and vendor lock-in.
In this article we provide a framework for data protection with a set of strategic selection criteria.
This article is intended towards any and all audience who deal with data security and cloud
security, executives, hands-on IT and Security professionals, and anyone with a passion
or interest in cybersecurity in general, across enterprises and service providers.

Recommendations for Cloud Crypto Service Selection

Enterprises need to develop a strategy for cloud data security early in their cloud migration
journey. They should implement data-centric security, preferably prior to the sensitive data being
migrated to the cloud. CSPs do a good job of infrastructure hardening and in implementing
security processes and policies, and they offer multiple tools to enable customers to secure their
workloads. But it is very important to understand that CSPs are not responsible or liable for the security of the
data that customers ingest into their services. As per the Shared Responsibility
Model, Security and Compliance is a shared responsibility between the CSP and the customer.
The separation of duties in this model is commonly referred to as Security “of” the Cloud
versus Security “in” the Cloud.

Figure 1: AWS Shared Responsibility Model

While the CSPs are responsible for the security “of” the cloud, where they are responsible for
protecting the infrastructure that runs all of the services offered in the cloud. This infrastructure
is composed of the hardware, software, networking, and facilities that run the cloud services. The
customer is responsible for the security “in” the cloud, and hence has the responsibility to ensure
the security of their data, while taking advantage of the scale, flexibility, features, and global
reach of the cloud. A lack of this understanding has contributed to so many data breaches as
witnessed in the recent past. Hence, an enterprise data security strategy is crucial to ensure data
is secure across all hosting locations (on-premises and in the cloud) and during migration, while
at rest, in transit, or in use. Enterprises are wise to avoid locking themselves into these native
CSP crypto services and to consider a better, CSP-agnostic, feature-rich, scalable, high
performance, global solution.

Strategic Selection Criteria

There are eight criteria for the selection of enterprise-grade hybrid and multi-cloud crypto
services:

1. Avoid vendor lock-in and ensure portability and extensibility – Choose a solution that
   can seamlessly apply to workloads hosted anywhere: on-premises or cloud, single or
   multiple CSPs, midrange or mainframe, Hadoop or cloud services. Migration o
   f workloads from one platform to the other, or migration from on-premises infrastructure to
   cloud, or switching across CSPs, should not require changing crypto services and key
   management controls.
   
   
2. Ensure adequate control of keys across all platforms – Whether HSMs are
   on-premises or hosted by a provider as a service, ensure full control and visibility of the
   keys generated and stored in these HSMs, as well as where they are being used, and
   which applications and users have access to them.
   
   
3. Drive toward state-less crypto services and key management – Traditional and typical
   crypto services and key management infrastructures rely on key storage, token vaults, etc.
   and create challenges with operationalizing distributed architecture due to their state-ful
   nature. They rely on eventual consistency and replication across the network, and this
   problem aggravates in a global deployment scenario. Hence, Crypto and key management
   services should be stateless, enable distributed deployment without requiring any sort of
   replication, synchronization, and eventual consistency. This allows for these distributed
   services to be accessible to any workloads hosted at any location. Data can be protected
   at one location, stay persistently protected while being moved to another location, and
   unprotected from the other location, if needed. This is what we refer to as the “Protect
   Here, Access There” model.
   
   
4. Strive for high availability and resiliency – Crypto services must be highly available
   and resilient, as enterprise business-critical functions depend on them. Ensure that the
   solution does not fall for the fallacies of distributed computing, where a network glitch
   can cause an operation to fail or time out, causing severe impacts to the organization in
   terms of inconsistent data, customer experience, and service outage. The solution needs
   to be resilient to prevent and minimize any network or infrastructure outage.
   
   
5. Strive for performance while not compromising security – The solution must be high
   performance, minimizing crypto operation overhead as well as avoiding dependencies on
   network availability and latency. The system must be able to handle bulk operations as
   well as high-throughput, delay-sensitive transactions. Needless to say, the solution must
   not achieve high performance by taking design shortcuts that can lead to key exposure or
   other security vulnerabilities.
   
   
6. Ensure adequate developer abstraction – Application developers like simplicity when
   consuming crypto services: methods/functions to invoke the services that abstract the
   underlying cryptography and key management. They do not want to be required to build
   crypto and key management expertise. Ensuring that they never have direct access to
   encryption keys helps avoid mistakes that can expose keys. They want to do the right
   thing, so choose a solution that makes it easier for them to do so.
   
   
7. Invest in feature-rich crypto solutions – Choose a solution that offers a variety of data
   protection formats that not only allow pseudonymization and anonymization of sensitive
   data, but also enable business processes, analytics workloads, etc. to operate on the data
   in its protected state.
   
   
1. Format-Preserving Encryption is a powerful data protection technology, and is
   currently becoming the de facto standard across the industry. FPE warrants a
   deeper examination, and there is a separate article that expands on FPE and its
   importance.
   
   
2. For PCI-DSS compliance, tokenization is the preferred method for credit card
   protection, so a data security solution or service must be able to tokenize
   credit card numbers. As explained earlier, a stateless tokenization solution is preferred to
   not only avoid consequences of token mapping table synchronization issue in a
   distributed deployment model, but also to enhance performance of the solution.
   
   
3. Privacy regulations such as GDPR and CCPA are driving data subjects’ rights for
   erasure of personal data (“right to be forgotten”), and the anonymization of data is
   an effective way for enterprises to comply. Anonymized values cannot be
   converted back to the original data, and Format-Preserving Hashing is a great
   way to achieve this.
   
   

Note: There is the only one solution in the market at this point that offers Format-Preserving Hash.

8. Consider CSP Crypto Services and BYOK for appropriate use cases only – When
   enterprises consume software as a service (SaaS) to store or process sensitive data, they
   face unique challenges. SaaS providers offer limited or no scope for custom
   development, so enterprises are typically restricted to very few options for data security.
   One option would be to leverage an encryption gateway solution, which acts as a web
   proxy to intercept and protect sensitive data prior to storing it in the SaaS cloud. The
   other option is to leverage the SaaS provider’s encryption capabilities, if available. Some
   of these SaaS providers also offer BYOK. In those cases, adopting the BYOK model makes
   sense. Most SaaS providers implement platform-level encryption (database, storage) by
   default, and typically also offer field-level encryption services at additional cost. These
   allow selection of fields to protect, encryption algorithm, and key strength to be used, as
   well as whether to use provider generated keys or BYOK. Opting for such SaaS providers’
   data-centric crypto services certainly provides added security. One way to exercise some
   control in the key management space is by adding BYOK to the mix, which helps in
   meeting some compliance and audit requirements, even though the challenges
   discussed above continue to apply. In a nutshell, if you can’t Bring Your Own Encryption
   (BYOE) to the cloud, at least Bring Your Own Key (BYOK).