GCP – Lost in translation: encryption, key management, and real security

Being compliant does not mean you’re secure. The definition of “being secure” varies too much across industries, organizations, and threat profiles—secure against what?—to ever match an external checklist.

Because of this, compliance and security have developed a peculiar relationship. Regulation is meant to provide guidance, through accepted best practices, from the body of knowledge for a given domain. But, because laws and regulations tend to evolve more slowly than technology, compliance regimes don’t foresee many new technologies. This applies to both technologies to secure and tools to secure them with. Many security professionals quote the “compliance is not security” cliche, but then ultimately look at external mandates to unlock budgets and decide on controls to implement.

Still, at a minimum, compliance remains a motivating force for some security decisions, and is even more critical in “regulated industries” such as finance and healthcare. Compliance also represents a stronger motivation than risk management for organizations that are in the initial stages of their security journey.

In today’s post we’ll look at data encryption, one of the major controls required by many regulations. Specifically, we’ll look at how encryption key management is an important part of data security as a whole, and develop some best practices to keep in mind when considering encryption key management.

Compliance and encryption today

One of the controls that many regulations and mandates include is data encryption. Most IT-relevant compliance applies to particular types of data, such as patient information, financial records, or payment card numbers. Unified Compliance Framework (UCF) data indicates (also here) that encryption is one of the most popular controls, and is included in hundreds of regulations and mandates they track. “Encrypt payment data”, “encrypt patient data”, “use methods such as encryption to protect data”, “encrypt data during transmission”, and similar phrases can be found in regulatory documents all around the globe, from US HIPAA to the Singapore Personal Data Protection Act.

However, few regulations address encryption key management in depth. Some contain minimal guidance like “don’t store keys with encrypted data” or suggest that “keys should be kept securely.” Only a few go into detail here: for example, PCI DSS mentions that keys are “encrypted with a key-encrypting key that is at least as strong as the data encrypting key, and that is stored separately from the data-encrypting key” and that the client “fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data.” They cover both the technical and process sides of key management such as that there is a “requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key custodian responsibilities.” (Source: PCI DSS 3.2.1). 

Another example is NIST 800-53 (and hence, FedRAMP) that states, “The organization establishes and manages cryptographic keys for required cryptography […]” This creates a requirement for an organization to manage its own encryption keys, but doesn’t get into the details. (A quick note, the NIST 800-57 document does go into key management details.) Some of the European banking regulations also prescribe that banks manage their own encryption keys, rather than rely on provider-managed encryption.

Still, deep and comprehensive key management guidance is a rarity in the world of compliance.

There are not many mandates or standards that prescribe the use of Hardware Security Modules (HSMs) for encryption, either (see this UCF link, for example). Some documents, like PCI DSS, mention HSMs as an acceptable choice, but do not try to force the organization to use it. Anecdotally, you could meet a security leader who believes they need an HSM “for compliance”, even though they can’t point at a specific mandate, law, or regulation that actually requires an HSM deployment.

The picture that forms is that one needs to encrypt the data to protect it, but the fate of a key used is ultimately up to the organization, not a regulator. 

To be effective against threats, encryption needs good key management

Let’s combine this set of compliance facts with another fact: while recent advances in technology made encryption ubiquitous—for example, see the proliferation of encrypted mobile devices and the rising TLS coverage of web traffic—enterprise key management remains a challenge for many organizations. 

In fact, using encryption for effective security—not just compliance checkbox —that stops real threats relies on solid key management. To generalize, encryption gains its security benefits from key management, not just from the strength of the algorithms and the math involved. It’s very possible that your encryption usage is compliant with the mandates you need to adhere to, but that your key management will not withstand the threats from actors who are interested in your data.

Therefore, while regulations may not compel you to use key management and maximize its protections over your data, the threats might. In fact, a peculiar notion emerged: some ransomware criminal groups have achieved a degree of encryption key management excellence that exceeds that of some organizations. 

Now, let’s add another dimension to this key management discussion: the cloud.

Cloud key management

Regulations evolve slower than technology. In fact, some of the mandates affecting encryption were written nearly 20 years ago (FIPS 140-2 was last updated in 2002, for example). Meanwhile, the cloud has emerged as both an enabler for new security mechanisms as well as a new environment to be secured. 

Pushed by both threats and regulators, cloud computing users took to data encryption—today mostly in transit and in storage, but later in use through methods like Confidential Computing. This opened a challenge of doing effective key management in the cloud, at least for those in the know.

But what does “effective” really mean? 

The methods used to fulfill key-management-related compliance requirements in an on-premise, proprietary, appliance-based model don’t translate directly to cloud. 

• Ultimately, the cloud makes good encryption key management easier to deploy and operationalize. Reducing key management to an API (as is the case for most cloud services) means that a large chunk of complexity is removed, making it easier to do things securely. This leads to faster development, which enables the more robust change management practices found in many compliance frameworks.

• Today, key management needs to scale with the cloud: latency, availability, and cloud services integration are essential to fulfilling the potential of the cloud, yet traditional appliance HSMs were not designed for the cloud age. Shifting from the data center to the cloud HSM addresses these concerns, enabling compliance, security, and cloud agility.

• The methods and tools that were traditionally used to demonstrate and complete a compliance assessment in an on-premise context will very likely not translate directly to the cloud. What emerged is sharing of responsibilities between the customer and the cloud provider. For example, physical security controls are now supported by cloud providers and can be addressed with standard downloadable compliance documentation.

• However, over time new regulatory concerns may arise. For example, data residency is not an issue when all data is on premise, but becomes a new area to understand, work through, and audit when workloads and key management shift to the cloud. Implementers need to ensure their cloud provider can support data residency (and even data sovereignty, sometimes) for key material, as well as for the workloads that the keys support.

• Beyond compliance, the actual threats to keep in mind will also have shifted—“insider threat” has a different meaning when much of the work is being done outside of the customer’s physical boundaries. For example, the customer can shift focus to ensuring that access to virtual machines is locked down, rather than focusing on physical access controls.  

What hasn’t changed? Having strong access control and governance remains essential, and account compromise is still the most prevalent mode of successful attack.

These are very big shifts in how IT overall and security, specifically, is deployed and operated. The consumption model is also different: a front-weighted CapEx investment followed by years of maintenance, vs. a turn-key, consumption-based, OpEx model with the promise of limitless keys and increased availability.

Best practices and next steps  

Despite the lag in compliance frameworks evolution, using simplified key management capabilities in the cloud to build key management governance leads to improved security. The breadth of controls to choose from allows a proper fit of control to workload.

Here are some of the key items Google Cloud users should keep in mind regarding encryption key management:

1. While the compliance compels you to encrypt, threats compel you to both encrypt well and do key management well. Focus on your threat assessment results, not just the compliance mandates, when implementing encryption and key management.

2. Key management is what makes encryption an effective control, not just for compliance but especially for security. Encryption delivers trust, but only if key management is done transparently and the keys are kept away from attackers.

3. When moving to the cloud, deploy the controls to ultimately balance your compliance demands and security requirements while also achieving the cloud agility demanded by the business. 

4. Utilize hardware-based encryption when truly necessary due to a specific threat assessment result or a specific mandate. Similarly, take control of the key if your threat profiles or regulations suggest that this is necessary for higher trust.

5. At the same time, assess whether the cost and scalability benefits of software-backed keys outweigh possibly outdated requirements to use hardware-backed keys stored on a machine you own and operate. 

6. Understand how Google achieves compliance globally and your responsibilities for the controls you need to establish to protect your data.

Compliance regulations were developed to provide organizations with a framework for keeping sensitive data secure. But, as we’ve seen here, being compliant and being truly secure can be two very different things. Encryption key management is one important way to bridge this gap. 

Learn more about security on Google Cloud.