Encryption of Cloud Data

1.0. Executive Summary

Organizations seeking to protect sensitive and mission-critical data quickly realize that there is no single answer to keep all systems completely secure. Online data security is a complex, rapidly evolving landscape, requiring robust and layered protections. Encryption is one tool in a comprehensive defense-in-depth strategy to mitigate the risk of accidental and intentional data breaches.

Like every other technology tool, implementation must work within a broader digital ecosystem, without disrupting the purpose that the system was designed to fulfill. Evaluating the benefits of encryption against potential tradeoffs such as cost, performance, and ongoing maintenance is at the heart of determining the most effective and efficient means of using encryption.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Although encryption is not a silver bullet of data or system security, it is one key tool that can be accompanied by a full arsenal of security services for a layered-defense approach to ensuring data is protected, even if accessed by unauthorized individuals. Additional security options to add to your IT solution will be covered.

2.0. Encryption for Compliance

2.1. HIPAA Encryption

Healthcare organizations (also called covered entities or CEs), business associates (BAs) and subcontractors that support the facilitation, processing or collecting of protected health information (PHI) must comply with the Healthcare Insurance Portability and Accountability Act (HIPAA) and HITECH Act enforced by the U.S. Department of Health & Human Services (HHS).

With addressable encryption implementation specifications, both a covered entity and business associate must consider implementing encryption as a method for safeguarding electronic protected health information (ePHI). If encryption is not used by a covered entity or business associate, clear documentation of the risk analysis, the decision not to encrypt, and the specifics of an equivalent level of protection must be in place to prove due diligence to protect ePHI.

Even when equivalent protection is possible, many organizations opt to encrypt to save on the costs of publically announcing and remediating a data breach, as encrypted data is not considered compromised if the encryption keys remain safe. This means a stolen laptop with patient records is not a reportable event if the PHI is encrypted, and the encryption keys remain safe. The costs of a data breach involving ePHI is one of many reasons data encryption is considered a best practice and sound investment for IT security.

A Ponemon Institute study, Patient Privacy & Data Security found that the average economic impact of a data breach has increased by $400,000 to a total of $2.3 million since 2010.

The economic impact can include investigation and legal fees, federal penalty costs, business loss due to downtime, decreased credibility and remediation or free credit monitoring for affected individuals. Costs will only continue to increase as the healthcare industry increases their reliance on electronic medical record systems (EMRs) and electronic health records (EHRs).

Unsecured, or unencrypted data, is a reoccurring and common theme in healthcare data breaches. Take these data breach cases, for example, that all involve unencrypted data and devices:

• The Alaska Medicaid program was fined $1.7 million after a breach resulting from an unencrypted USB device that contained just 501 patient records was stolen.
• Massachusetts Eye and Ear Associates was fined $1.5 million after a breach resulting from the theft of an unencrypted laptop containing about 3,600 of its patients and research subjects.
• Advocate Health Care lost four million patient records when four unencrypted computers were stolen from their facility; the second largest health data breach since 2009.
• TRICARE Management had unencrypted backup tapes stolen, affecting 4.9 million individuals; the largest health data breach to date.

Only unencrypted data falls under the scope of the HIPAA Breach Notification Rule that requires patient, media and Dept. of Health and Human Services notification. Meaning, if you encrypt your data, you do not have to report a data breach to the government unless you have reason to believe that the encryption keys were compromised.

While encryption is “addressable” under HIPAA, it is highly recommended. OCR (Office for Civil Rights) Director Leon Rodriguez was quoted: “…Encryption is an easy method for making lost information unusable, unreadable and undecipherable.” We will not debate if encryption is “easy” in this white paper, but it is key to recognize that the Department of Health and Human Services, who enforces HIPAA violation investigation and penalties through its Office for Civil Rights considers encryption well within reach with the burden of proof on the organization that chooses not to implement it.

The HIPAA Security Rule for healthcare organizations handling electronic protected health information (ePHI) dictates that organizations must:

In accordance with §164.306… Implement a mechanism to encrypt and decrypt electronic protected health information. (45 CFR § 164.312(a)(2)(iv))

HIPAA also mandates that organizations must:

§164.306(e)(2)(ii): Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. Protecting ePHI at rest and in transit means encrypting not only data collected or processed, but also data stored or archived as backups.

HIPAA Encryption of Data at Rest
The HIPAA Breach Notification Rule provides guidance on encryption, stating that the proper standards for encrypting data at rest are aligned with the NIST (National Institute of Standards and Technology) Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices. The NIST standard approves of the AES algorithm (Advanced Encryption Standard).

Data at rest can include database fileshares, workstations, laptops, tablets, iPads, phones, USB drives, flash drives, data backup tapes, CDs and DVDs, cameras and external hard drives.

The SANS Institute, specializing in Internet security training, recommends employing whole-disk or folder-level encryption for ePHI. For ePHI in databases, they recommend full database or column-level encryption. Additionally, key management procedures and processes that separate duties and least-privilege for users and applications are important for ePHI at rest. Lastly, they recommend hashing or digitally signing all stored ePHI.

HIPAA Encryption of Data in Transit
For data in transit (also referred to as “in flight”), complying with the Federal Information Processing Standards (FIPS) 140-2 also includes standards described in NIST Special Publication 800-52, 800-77 and 800-113. Data in transit crosses the Internet, wireless networks, from tier to tier within an application, or across wired or wireless connections without being stored. Data in transit remains in a non-persistent state - where it's not being written to disk or other media or being retained.

The SANS Institute recommends implementing a VPN (Virtual Private Network) using either IPSec or SSL for all remote systems that need to transmit ePHI, and to implement encryption for all systems and users that may need to email ePHI. Many organizations add two-factor authentication to their VPN login process such as Duo Security to further protect data and prevent unauthorized use.

HIPAA Encryption in the Cloud and Data Center
Encrypting data at rest and in transit is key to protecting ePHI. Encryption should be addressed both in transit through SSL connections or VPN tunnels as well as at the disk level. If IT infrastructure is outsourced, make sure to read the details of their audit reports and that the hosting provider will sign a Business Associate Agreement (BAA).

Reviewing the hosting provider’s data breach insurance policy can also be a key indicator of the level of attention and priority given to preventing data breaches. HIPAA compliant data centers should be able to turn over a complete HIPAA risk assessment performance against the OCR HIPAA Audit protocol guidelines or equivalent documentation of controls that prove thorough due diligence to protect sensitive data.

Particularly in the cloud, encryption is an important aspect of keeping data safe and in compliance with the HIPAA Security Rule. A HIPAA compliant cloud should provide encryption of data at rest, including data that is stored as backups and archived as part of an IT disaster recovery plan. The cloud should also provide encryption of data in transit for complete security.

2.2. PCI DSS Encryption

The PCI DSS (Payment Card Industry Data Security Standard) requires companies that deal with credit cardholder data to employ encryption or other technology to render data unreadable:

3.4 Render PAN (Primary Account Number) unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography (hash must be of the entire PAN)
• Truncation (hashing cannot be used to replace the truncated segment of PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures

3.4.1.c Verify that cardholder data on removable media is encrypted wherever stored.

When it comes to data storage, the PCI Security Standards Council (SSC) recommends that merchants render cardholder data unreadable by using strong cryptography, and to use other layered security technologies to minimize risk of criminal exploits. They also warn against locating servers or other payment card system storage devices outside of a locked, fully-secured and access-controlled room.

One way to achieve this is by partnering with a PCI hosting provider that can meet the physical and technical requirements of the standard by maintaining a PCI compliant data center. Physical security should include locked server racks, suites and cages, and dual-identification control access to data centers. Environmental control can be achieved with 24x7 monitoring, logged surveillance and alarm systems.

The PCI SSC specifically recommends ‘strong cryptography’ which they define as cryptography that is based on industry-tested and accepted algorithms, key lengths and proper key management practices. They call out AES (128 bits and higher) as an example of strong cryptography and refer technical users to the NIST Special Publication 800-57 (three parts) on recommendations for key management.

P2PE (Point-to-Point Encryption)
Merchants that transmit cardholder data from a POS terminal (Point of Sale) to a payment processor should use point-to-point encryption (P2PE) to secure data and reduce risk of unauthorized interception during transmission. While the PCI SSC released a very detailed document outlining infrastructure encryption requirements, a high-level overview of the six main areas that must be secured within the SCD (secure cryptographic devices, or the hardware/hardware level) include:

1. Encryption Device Management: Use secure encryption devices and protect devices from tampering. Requirements include building/using PCI-approved POI devices (Point of Interaction, or the device that accepts PINs), and securely managing equipment used to encrypt account data. The POI device should be managed by the solution provider and hardware encryption should be performed by the device.
2. Application Security: Secure applications in the P2PE environment. Requirements include protecting PAN/SAD (Primary Account Number and Sensitive Authentication Data); developing and maintaining secure apps; and implementing secure app-management processes. Apps should be on PCI-approved POI devices.
3. Encryption Environment: Secure environments where POI devices are present. Requirements include not storing CHD after transactions are complete, securing POI devices throughout their lifecycle, implementing secure device management processes and maintaining a P2PE Instruction Manual (PIM) for merchants.
4. Segmentation between Encryption and Decryption Environments: Segregate duties/functions between encryption and decryption environments. Requirements include all decryption operations managed by solution provider; merchant has no access to the encryption or encryption environment and the merchant has no involvement in the operations.
5. Decryption Environment and Device Management: Secure decryption environments/devices. Requirements include using only approved decryption devices; securing all decryption systems and devices; implementing secure device-management processes and maintaining secure decryption environment. The merchant must also have no access to the decryption environment and the decryption environment must be PCI DSS compliant.
6. Cryptographic Key Operations: Use strong cryptographic keys and secure key management functions. Requirements include using secure encryption and key generation methods; and distribute, load, use and administrate cryptographic keys in a secure manner.

See the PCI Point-to-Point Encryption: Solution Requirements and Testing Procedures v1.1.1 Encryption, Decryption and Key Management within SCDs (Hardware/Hardware) document for more details and testing procedures to help you build and verify a valid P2PE solution that meets the PCI SSC standards for hardware encryption.

2.3. SOX Encryption

SOX, or Sarbanes-Oxley Act, was created to protect the sensitive financial reporting data in public companies. While not explicitly stated, encryption can help satisfy the requirements as follows:

DS5.11 Exchange of Sensitive Data: Exchange sensitive transaction data only over a trusted path or medium with controls to provide authenticity of content, proof of submission, proof of receipt, and non-repudiation of origin.

DS11.6 Security Requirements for Data Management: Define and implement policies and procedures to identify and apply security requirements applicable to the receipt, processing, storage and output of data to meet business objectives, organizational security policy, and regulatory requirements.

DS5.8 Cryptographic Key Management: Determine that policies and procedures are in place to organize the generation, change, revocation, destruction, distribution, certification, storage, entry, use and archiving of cryptographic keys to ensure the protection of keys against modification and unauthorized disclosure.

The SANS Institute recommends more general encryption best practices, such as employing remote management using secure encrypted channels (SSH, SSL, and IPSec); encrypting security device log data at rest and in transit; using dedicated key storage devices and apps; role-based key access policies; key recovery procedures, and guidance of key handling in different environments.

3.0. Encryption Guidelines

3.1. Find, Classify and Determine What to Encrypt

Determining what kind of data to encrypt is the first objective to protecting it. Your organization needs to determine where your data is located, how sensitive it is and what is in your data repositories in order to protect it with encryption.

Classifying your data as regulated, or data that falls under the data protection laws such as HIPAA or PCI, can clarify what you should encrypt. A few examples of regulated data include personally identifiable data, patient data or credit cardholder data. It can be inefficient to attempt to encrypt everything – finding the sensitive data that is transmitted as network traffic, found in file shares, databases and all endpoints helps you specify where it is necessary to employ encryption.

Non-centralized and unstructured repositories such as Word documents, spreadsheets and text files are also at risk to be overlooked and unsecured. A recent healthcare data breach by the Oregon Health & Science University (OHSU) was a result of several health departments using unencrypted Google spreadsheets to maintain and exchange patient information.¹⁸ Data sharing outside of the centralized database can lead to unsecure practices.

Confidential data is another category your data may fall under – this might include client contracts, purchasing agreements, etc. While a breach of this type of data may not get you fined by federal law or regulatory entities, your organization likely does not want these documents available to the public. Non-public data may be employee-related, such as salary history, payroll, leave, etc. And public information is data available on your website, such as marketing materials that are intended to be distributed publicly.

After classifying your data, you should be able to make an encryption determination about which categories of data you want to encrypt. Creating an asset inventory that correlates classified data to certain devices, disks, storage area networks and servers is next as you consider where you should employ encryption.

3.2. Encryption Guidelines

3.2.1. Data at Rest

Data at rest, or in storage, may include end user devices such as personal computers, mobile devices and removable storage media. Encryption for stored data can be applied to one individual file with sensitive data or applied to all stored data, as previously mentioned.

NIST explains some of the high-level security controls required for secure and encrypted stored data:

Authentication
Encrypted stored data requires users to verify their identity and authenticate to gain access by means of an authentication method; including passwords, personal ID numbers (PINs), biometrics, tokens, etc.

Data Backups
While storing backups at an offsite location is good practice for organizations in case of a disaster, they must also be encrypted and secured. Traditional tape backup puts you at risk of physical loss of data. Using a cloud-based disaster recovery solution eliminates tape backup and virtualizes the entire operation system, apps, patches and data.

Encrypting sensitive data before it is sent to an offsite backup facility is another way to ensure data is secure. NIST recommends any local backups should also be encrypted and physically secured within the organization’s facilities.

End User Devices
Securing and maintaining device operating systems, apps and wired or wireless network traffic should also help reduce the risk of a data breach.

See section 5.0. Choosing Encryption Techniques for a more technical overview of encrypting data at rest.

3.2.2. Data in Transit

Although encryption of data at rest is mainly the focus for security since it is more likely that a hacker will target systems with data on local drives or storage networks, encrypting data in transit is also important to avoid potential interception by unauthorized persons. Data in transit may include data that travels across the Internet, wireless networks, from tier to tier within an application, across wired or wireless connections in a non-persistent state.

Complying with the Federal Information Processing Standards (FIPS) 140-2 that includes the standards described in NIST SP 800-52, -77 and -113 can provide acceptable encryption for data in transit for the healthcare industry, which can also work for other industries.

Virtual Private Network (VPN)
When using a VPN (Virtual Private Network), you are connecting one network to another network in order to access a server remotely – this means you are also transmitting data that needs to be encrypted. VPNs can use a variety of secure protocols to transmit, or tunnel traffic from one network to another securely. The data is encrypted while sent from one network to another, and the VPN server decrypts the data and forwards it to the receiving server.

Two-Factor Authentication
Two-factor authentication for VPN (Virtual Private Network) access is an optimal security measure to protect against online fraud and unauthorized access for clients that connect to their networks from a remote location.

Two-factor authentication (also known as dual-factor or multi-factor) requires the use of one form of authorization (username/password), and an additional form of authentication to gain access to a network remotely. Two-factor authentication provides an extra layer of protection to ensure the user is truly the one who is allowed access to the network, and to protect against unauthorized entry.

SSL Certificates
SSL (Secure Sockets Layer) is a cryptographic protocol that can provide security as information is transmitted over the Internet. When a browser tries to connect with a website secured with SSL, the browser first requests that the web server identify itself. After the server sends a copy of its SSL certificate, the browser checks its credentials and approves it. The server then sends a digital signature to start an encrypted SSL session, and then encrypted data is shared between the browser and server.

SFTP
Another method for securing data in transit is with SFTP, the SSH File Transfer Protocol that allows for secure file transfers between hosts as well as access/management of files on remote file systems. SFTP ensures that the data being transmitted is secured as well as your login credentials.

To create a strong layered security solution, use both a VPN and SSL connection. A VPN can transmit data securely even for standards that don’t have encryption built in. While the file itself isn’t encrypted, the entire path that the file traverses is encrypted.

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

To learn more about Choosing Encryption Techniques, Keys and Encryption in the cloud, download the complete version of Online Tech's Encryption of Cloud Data whitepaper.