How To Protect Data in Flight

Accessing cloud-based resources, whether they be IaaS/PaaS/SaaS-based, is very convenient. With a browser and Internet connection, you are up and running. No driving to your work office, no need to log into the corporate network. Just open up your web browser and go. This convenience, however, comes with a security risk. All of your business work is conducted over an insecure communication network. Unlike your office network, where the network link between you and the data center is under corporate control and is physically secure, the cloud access link is over the Internet.

The wild, uncontrolled, used-by-everyone-in-the-world Internet. There are no guarantees about who else has (or does not have) access to your network communication link. In fact, from a security perspective, we assume that the cloud link (i.e., the Internet) is unsecured and hostile. Any sensitive or private information WILL be accessed by someone else. This is why we have a need to protect “data in flight.” The data may be safe once it gets to the cloud provider, but during the transmission we need to protect it and ensure it remains private. To ensure secure communication across the Internet, a key fundamental cloud security principle is to encrypt the data transmission whenever you engage with a cloud resource. In this blog we introduce the security concept of protecting “data in flight” and explain how it operates.

The good news is that this data in flight protection is easier that it sounds. Since just about all traffic is done via the web browser (HTTP protocol), all you have to do is ensure that the HTTPS protocol is used by default in your browser. This means that instead of using http://myurl…, make sure it uses https://myurl… .

Secure HTTP (HTTPS) is a security protocol. It uses a secure transport layer security mechanism called SSL, or its newer version TLS, to transmit HTTP traffic (i.e., your browser traffic) securely by encrypting the data. When HTTPS is used you can be certain that your confidential data (like your credit card information) is safe from eavesdropping. If someone does intercept all of your encrypted data, they won’t be able to decrypt it.

TLS (transport layer security) data encryption is based on two related but different encryption technologies called symmetric key encryption and asymmetric key encryption. Symmetric key encryption means that two users who wish to communicate must share the same encryption key to encrypt and decrypt a message. For example, if I encrypt a message with an encryption key-A, then the receiver of my encrypted message must have the same encryption key-A to decrypt the message.

Asymmetric key encryption is different. It uses two keys, a public key and a private key. The public key is distributed to anyone who wants to communicate with me. They encrypt their message with my public key and send it to me. When I receive it I use my private key to decrypt the message.

The advantage that the asymmetric encryption has is that initiating communication with a stranger is easy. Just use the person’s public key, which is usually obtained via a certificate authority. To initiate secure communication with symmetric encryption requires that the initiator somehow knows ahead of time what the symmetric key is, or must acquire it in a secure manner. That becomes impractical if the person is halfway around the world. However, symmetric key encryption does have one advantage over asymmetric encryption. Symmetric encryption is computationally faster than asymmetric encryption; in fact asymmetric encryption processing is about 1,000 times slower (http://​windowsitpro​.com/​s​e​c​u​r​i​t​y​/​s​y​m​m​e​t​r​i​c​-​v​s​-​a​s​y​m​m​e​t​r​i​c​-​c​i​p​hers). This is important because symmetric processing can speed up the transmission and processing of secured data.

The astute observer will note that the advantages and disadvantages of each encryption method are complementary. Therefore, TLS uses both techniques to securely transmit HTTP traffic. It uses asymmetric key encryption to initiate a secure communication link between the two parties. Once that secure link is established, TLS securely exchanges a symmetric key. Going forward, TLS uses the symmetric encryption technique for all data transmission. This maximizes performance while still ensuring safe and convenient access to cloud resources.

Key Management in the Cloud

In my previous cloud security blogs, I mentioned the need to use key-based encryption for protecting data. Whether the data is in flight (i.e., being transmitted) or at rest (i.e., stored), it must be encrypted to ensure confidentiality, integrity and availability. Managing encryption keys can be challenging. There are different key types (symmetric vs. asymmetric), key strengths (128-bit through 2048-bit and greater), key usage (privacy, key exchange, authentication and digital signature) and key encryption algorithms (AES, 3DES, SHA-1, SHA-2, MD5, etc). Furthermore, each data end point, like storage or server, requires an integration point that also needs to be managed. For example, for storage we need an encryption integration point for each storage medium (disk, SAN, NAS or tape).

To help manage all of these encryption security components cloud security managers should utilize a centralized Key Management System (KMS) solution. While it is possible to use specific, individual point solutions from different vendors to handle parts of the key management tasks, a centralized approach is most preferable and cost effective. In this blog, I will examine the components of a generic KMS and use an example from Amazon Web Services to illustrate how it can be implemented.

One item to note is that the industry for key management solutions is still evolving, therefore you will see various names, terms and acronyms being used: Enterprise Key Management (EKM), Enterprise Key Management System (EKMS) and Encryption Key Management (EKM). All of these refer to the same concept we call KMS.

A KMS consists of two main components, a core key management server and the end-target integration points.

KMS server

A mature KMS performs five functions through the core key management server:

1. Key Generation: a KMS must be able to generate symmetric and asymmetric keys of varying bit lengths. These parameters are determined via your security policies and configured through the tool’s administrative console.
2. Secure Storage: every key used for encryption must be well-protected and secured. This means encrypting the keys themselves. This is called key wrapping.
3. Key Lifecycle Tracking: a key has a lifespan and very specific stages or states that it goes through. A common key lifecycle used is from NIST’s SP800-57 Recommendation for Key Management — Part 1: General (Revision 3): pre-activation state, active state, deactivated state, destroyed state, compromised state and destroyed compromised state.
4. Backup Mechanism: if the sets of encryption keys are ever lost, then the encrypted data is lost. To protect yourself against this the KMS must provide a secure method for backing up the encryption keys.
5. Auditing: a mature KMS will make reporting and auditing easier by providing documentation of what keys are being used, for what purpose and who has access to them. This information is critical for regulation and compliance audits.

To provide even greater protection and security, a KMS may optionally use a Hardware Security Module (HSM). A HSM is a self-contained hardware appliance that stores keys in a physically tamper-resistant device. If the KMS uses a HSM, all keys are stored in the HSM exclusively. These two components communicate through a secure, encrypted network link. This extra level of security may be required of some businesses’ compliance audit.

End-Target Integration Points
The second component of a KSM is the end-target integration point where the encrypted data resides (usually a storage device) or where the data is being sent (usually a server). These can also be called “service agents.” It is the service agents that actually use the encryption keys to convert plaintext data into encrypted data and then store it on a storage device, and then reverse the process when the data is accessed or transmitted. In order to use a KMS you must ensure that the end target has a service agent that can interoperate with the KMS. Not every KMS has support every storage device and/or server platform. Usually it is the KMS provider that provides the service agents to support a variety of storage/server devices.

Key Management in the Cloud
It is possible to extend a KMS solution that is in your data center to include IT components residing in the cloud. However, it is more convenient to use a cloud-based KMS, especially if the cloud provider offers one directly. This is the case with Amazon Web Services (AWS). As part of their IaaS offering, they have a KMS service where key management for all cloud data is performed right in the cloud environment. This ensures maximum performance and throughput since the key distribution and processing is done close to where the data resides. Just as important, a cloud provider-based KMS solution integrates natively with their storage, server and database IaaS offering. In AWS, you can use key encryption through their KMS to store encrypted data on NAS disks (EBS), on tape (Glacier), in a database (RDS/Oracle, RDS/SQL), warehouse (RedShift), on a per file basis (S3) and for Windows/Linux servers (EC2). AWS takes care of integrating the key encryption regardless of where or how you store your data. AWS also offers the equivalent of a HSM called CloudHSM where the encryption keys are stored on a physically tamper-resistant device for greater protection.

Using a cloud based KMS, like AWS’ KMS, greatly eases the work and planning involved in protecting data at rest and data in flight. With a proper implementation IT operations in the cloud can be just as secure as any IT operations in a data center.