Thales e-Security Blog

Is All Encryption Equal?

Rick Killpack More About This Author >

Data encryption has been around almost since the age of computers. In truth, anyone with minimal experience can write a simple script that uses default services built into virtually every OS to encrypt data. In Linux, for instance, it takes four openSSL commands to generate an encryption key and encrypt data. However, simply encrypting data is not a sufficient control when storing data in the cloud. Several factors must also be considered to determine the right encryption methodology. Encryption methodology is determined by the following factors:

  • What are you trying to protect?
  • Who are you trying to protect your data from?
  • Where is the data being accessed?

The answer to these questions changes your encryption strategy. Let’s look at each one individually.

Is All Encryption Equal

What are you trying to protect?

In an efficient world, security teams would love to lock down and encrypt everything and create strict and complicated controls to access the data. This position would minimize any potential breach. However, there is a cost associated with every piece of data you are trying to protect. There are security services costs, compute costs, management costs and user experience costs. A mature enterprise understands that all data is not the same and will continue to balance the cost of security versus the cost of doing business.

For an enterprise to find the right balance, they must be disciplined and knowledgeable of how each data type impacts their business. A rigorous data classification process should be put into place that will examine all data to determine what types of security controls should be implemented to manage the data. Unfortunately, experience has shown that enterprise data classification projects take a lot of time and resources that need to be budgeted and spread out over time as to not disrupt day-to-day business.

Encrypt everything

Because of the complexity of data classification, many organizations take the posture of “encrypt everything” and then add or release controls as the data classification policies start to roll out. The “encrypt everything” strategy will only work if there is no impact or required modifications at the OS, data and application layers. This is an obvious conclusion when you consider the potential OS, devices, applications and locations the data may potentially reside. Considering these requirements, there is only one practical method of encrypting all data on premises and in the cloud. You must encrypt the entire disk — or volume — and ensure it is decrypted transparent to the OS, application and/or user that is accessing the data.

Who are you trying to protect your data from?

Many operating systems, hardware providers and cloud service providers include full disk encryption services, often at no charge. Many enterprises choose this as their first option because it is integrated and often a cost-efficient method. The problem with this solution is that it really doesn’t address the most common attack vector, especially when moving data to the cloud. Full disk encryption (FDE) is effective if you want to ensure someone doesn’t steal your disk. If a perpetrator steals an encrypted disk, they don’t have the sufficient mechanisms to decrypt it. However, if the perpetrator steals a privileged user account and gets unauthorized access to the OS, the disk, or volume, the data is unencrypted when the disk is mounted. Although this may have some value for on-premises data, it really doesn’t have the same value in the cloud. The historical precedence of a physical disc in a CSP infrastructure being taken is very low. For the “encrypt everything” strategy to be effective in the cloud, the decryption process must be tied to a specific authorization policy above and beyond simple disk/volume mount events and must also leverage a key or set of keys that is external to the OS, device, and application to perform the encryption/decryption processes.

The value of role-based encryption

An authorization process added to an encryption service that is independent and transparent to the OS, application, and user is an effective way to “encrypt everything” in the cloud, as well as, on-premises. The authorization process needs to look at who or what is trying to access the encrypted data and make a quick decision about whether the requested operation should be granted. The authorization process should be robust enough to apply configured whitelists, blacklists, and specific access identification information when decrypting data. With authorization is added to encryption, enterprises can store data in the cloud and be assured that privileged cloud provider users, privileged enterprise users, or unauthorized users do not get access to the data.

Importance of external key management

Even authorization policies can be bypassed if an unauthorized user or service gets access to the encryption key. The best way to protect against this is to generate multiple keys for various data sets and maintain those keys external to the service that is storing the data. To maximize protection, the key should never be exposed to human interaction or application service. The key should be controlled and managed by a tightened encryption service that performs the encryption processes in behalf of the users and applications.

An effective encryption service should be able to leverage multiple keys which mitigates risk by reducing the attack surface. If you use a different key for different segments of data (a file, a directory, a volume, a database, an application, or user), you mitigate the risk of losing your entire data set if the key is somehow compromised. The encryption service that is being used should be able to efficiently maintain the full lifecycle of all of the keys and key types as an independent data services. An external service protects against someone stealing the key by simply stealing the data set or services.

Another value of an external key management service is that the same key can be applied to unencrypt data in multiple repositories. As data passes from one repository to another, it may not be necessary to unencrypt the data during transfer. This becomes a powerful strategy as multiple cloud providers and multiple endpoint devices can be used to access the same data sets.

Where is the data being accessed?

Another consideration in your encryption strategy is to determine where the data is being accessed. An enterprise can effectively encrypt everything if it has full control of the data repository. However, enterprises are using innovative cloud serverless microservices to fully maximize portability. Microservices utilize shared data stores that are controlled by the cloud service provider. Without enterprise control of the storage services, it is not feasible to create authorization policies at the data layer that are unique per service accessing the data. As more applications are being built in a microservice (known as PaaS) environment, it is important to have an encryption strategy that can enforce authorized access at the application and sometimes at the device layer.

Encrypting at the application layer requires a separate service that can run inside the cloud provider environment as well as outside the cloud provider framework. The next-gen application built using microservices can make encryption and decryption calls when data needs to be represented in the UI and/or stored. Although it is possible to encrypt all data fields at the application layer, the cost of doing so often outweighs the value. For this reason, it is important that you have a good understanding of the impact to your business if an individual data column or value is compromised. An effective data classification process will allow you to set specific encryption policies independent of the data layer.

Another key advantage to encrypting at the application layer is that the security policy is portable. If you build your application in a hybrid PaaS platform, you do not have to modify your application to leverage the encryption service as it is not dependent on the CSP infrastructure or data repository.

In my next blog, I’ll discuss why enterprises should control the encryption keys when storing data in the cloud. In the meantime, leave a comment below, check out Thales eSecurity’s data security and encryption page, and/or tweet me @rjkcasl.