Protecting patient data in the cloud: Encryption from A-Z, part II

By Kurt Hagerman
08:23 AM

As we discussed in Part I of this series, encryption plays a vital role in healthcare IT security, but not everyone understands the ins and outs. In Part I of our articles on encryption, we talked about the methods that do and don’t meet HIPAA encryption requirements. Today we’re going to focus on the other more critical components of encryption: selecting an appropriate algorithm/method, managing the keys used in the encryption process, encrypting data in transit and encryption verification.

Encryption Algorithms and Methods

When it comes to rendering data unreadable, you have several methods at your disposal. These include encryption algorithms like AES, Blowfish, RSA and 3DES; one-way hashing using strong hashing functions; truncation; and index tokens and pads.

The most common method is using an encryption algorithm. There are several crypto libraries that contain full encryption/decryption routines using one or more freely available algorithms that can be integrated into each of the encryption methods described in Part I of this series. One-way hashing is another option but is typically only implemented in application-layer encryption.

The most important consideration here is selecting what is considered “strong encryption.”  Most regulatory requirements mandate the use of strong encryption without providing specific guidance for what that means. Strong cryptography is a general term applied to cryptographic systems or components that are considered highly resistant to cryptanalysis.  This is a complex issue and there is no standard scale for measuring or defining the term.  There are certain algorithms that are considered strong by the information security community, including AES, the most popular, and PGP, Blowfish and triple DES.  Key length is also a factor in determining the strength of an algorithm.  For example, for AES, a minimum key length of 256 bits is considered strong.

Managing encryption keys

An encryption solution is only as strong as the protection provided to the encryption keys, which makes meticulous key management a baseline requirement for healthcare IT security. While encryption keys can be stored and secured on servers using software-based methods, the most secure way to manage keys is to leverage the functionality of hardware security modules (HSM).  These are devices that are specially designed to securely store and provide key management functionality using tamper resistant hardware components.

Effective key management involves several important elements.

  • Generating keys: take a look at your current generation procedures to make sure your system is creating strong keys. It’s also critical to make sure your system prevents the unauthorized substitution of keys.
  • Distribution: the encryption solution must distribute keys securely, meaning the keys are distributed only to authorized custodians or authorized key management devices (HSMs), and are never distributed in the clear.
  • Storage: restrict access to cryptographic keys to the fewest number of custodians necessary and store those keys in as few locations as possible. Keys should be stored in encrypted format, with key-encrypting keys kept separate from data-encrypting keys.
  • Key rotation: make sure that periodic key changes are required at the end of the defined crypto period, whether it’s after a specified amount of cipher-text has been generated or after a certain amount of time.
  • Retiring or replacing keys: Any key whose integrity has been, or is suspected of having been, weakened or compromised must be securely retired, with a new key created.  Keys should also be changed any time a key custodian or person with access to encryption keys leaves the organization.

Encrypting Data in Transit

Until now, our discussion has focused on encrypting ePHI in storage, but we can’t overlook data in transit. Let’s turn our attention to securing the transmission of ePHI across open, public networks. While protecting medical data in transmission involves many of the controls and practices listed above, additional measures must be taken that depend mostly on the kind of transmission.

  • End-user messaging technologies like e-mail, chat or instant messaging should never be used to send unprotected ePHI. Instead strong cryptography and security protocols such as SSL/TLS or IPSEC are mandatory, with verification that the data is definitely unreadable.
  • Wireless networks involve a slightly different set of best practices. Whenever a wireless environment is connected to the data environment, all wireless vendor defaults must be changed at installation, including encryption keys, passwords, and SNMP community strings. Configuration settings should be updated to only support strong encryption for both wireless transmission and authentication.  The current secure standard is to use WPA for wireless security.

Encryption Verification

Implementing top-notch encryption is important, but it’s only the first step in protecting your data. Take these extra steps on a regular basis to verify that your procedures are current and effective:

  • Routinely check files from your data repositories and removable media like backup tapes and audit logs to verify the ePHI is unreadable.
  • Observe wireless transactions in real time to confirm the data is encrypted during transit.
  • Verify that your network accepts only trusted keys and certificates.
  • Check that your protocols do not support insecure or outdated versions or configurations.
  • Periodically examine user access lists to verify that cryptographic key access is restricted to the fewest number of custodians possible.

When we’re talking about medical data in the cloud, security can literally be a matter of life and death. Multi-layered security is a must – and by improving your encryption game today, you’ll be making your healthcare cloud a much safer and more successful place.

Want to get more stories like this one? Get daily news updates from Healthcare IT News.
Your subscription has been saved.
Something went wrong. Please try again.