Encrypting Data at Rest on Servers

Implications for Health Centers

It is common practice today to encrypt data at rest, that is, data stored on servers. Like many smaller healthcare organizations, Federally Qualified Health Centers (FQHC) are particularly vulnerable to potential attack and infiltration by data hackers for several reasons: they tend to have fewer technical support staff, resource limitations make it harder to assess, implement, and maintain safe data practices, and organizational inertia limits preventive action when no threat is perceived.

To build off an old adage, no one ever got fired for encrypting their data. But what protection does that really provide? Is just encrypting data enough?

First, let’s distinguish between three methods for encrypting data at rest.

Full-disk encryption. Most modern operating systems (like Linux or Windows Server) provide the capability to encrypt their disks in their entirety. This is accomplished with symmetric encryption whereby there is a key or passphrase that a computer operator has to enter when the disks are encrypted and when the system boots to allow access to the data. Typically, the password must be manually entered on the physical server console, though some virtualized and cloud-based environments offer remote passphrase entry and varying degrees of passphrase management and automation. With full-disk encryption, software installed on the server does not need to know or do anything special to operate normally: the operating system provides transparent access to the encrypted data as necessary with very little performance loss. But note that the initial encryption needs to be done on a new disk (or set of disks) as an existing disk will be wiped clean in the process. So it’s easiest to do this during an initial deployment or migration to a new server.

File system encryption. Physical disks are typically divided into one or more file systems by the operating system.  As an alternative to full-disk encryption, file system encryption allows administrators to encrypt only selected file systems (or even just selected folders within file systems). This makes it possible to configure a server than can boot without a passphrase; and then require a passphase only after the system is up and running and needs to access its encrypted file systems.  Similar to full-disk encryption, the encryption is transparently provided to applications by the operating system.  Unlike full-disk encryption, developers and administrators need to be careful not to store sensitive files on non-encrypted file systems.

Database encryption.  Another way to encrypt data at rest is at the database level: The database software (Oracle, SQL Server) can provide application-level encryption. Like operating system level encryption, a key or passphrase is entered by an operator when the database starts up, after which all database operations access the encrypted data transparently (hence the name: Both Oracle and Microsoft SQL Server call the feature “Transparent Data Encryption”). For servers that may store sensitive data in files outside the database, this provides less protection than encrypting the entire file system, but likely protects the most sensitive data on the system.

What kind of protection does encrypting data at rest really provide? Here are a few salient points:

Benefits of Encrypting Data at Rest

• First and foremost, encrypting data at rest protects the organization from the physical theft of the file system storage devices (which is why end-user mobile devices from laptops to cell phones should always be encrypted). While this might sound unlikely, the physical disk devices are only as secure as the data center where they are located. While data center access control policy is usually quite strict, in practice it can be quite lax. Door entry can employ weak precautions (like old push-button unlock devices), and the proliferation of easily-swappable modular disks for quick maintenance makes removing a disk quite easy.
• Encrypting data at rest can protect the organization from unauthorized access to data when computer hardware is sent for repair or discarded.
• Encrypting data at rest can help to satisfy information security or regulatory requirements such as the Payment Card Industry Data Security Standard (PCI DSS) or the Health Insurance Portability and Accountability Act (HIPAA).
• In some deployments, the actual file system where data resides is somewhat disconnected from the server upon which applications are loaded either through the use of a storage area network (SAN) or cloud-based storage. This introduces the possibility that an intruder could break in to the storage subsystem but not the rest of the system. Encrypting the storage subsystem can protect against such attacks.

Limitations of Encrypting Data at Rest

• Encryption of data at rest provides little protection against intrusions in which a hacker gains remote privileged access to a running server in which the passphrase has already been entered.
• Even more so, if the applications that access the encrypted files or databases (web applications, query systems) are not themselves secured, a hacker who penetrates one of these applications gains access to the data, whether it is encrypted or not.
• For database encryption, note that some database management systems only support data encryption in more advanced (read more expensive) versions of the software.
• When full-disk encryption is enabled on a physical (non-virtualized) server, remember that an operator – a human being – will need to type the passphrase into a console whenever the system starts up. For database-level encryption, the passphrase will need to be entered when the database starts up. While this intervention increases the level of protection, it is at the expense of convenience, as systems cannot reboot automatically without a passphrase or even without someone actually being in the server room which can be especially inconvenient if the system manager is not collocated with the hardware. File system encryption can mitigate some of these startup issues. And, of course, if that passphrase is ever lost your data will be encrypted forever.

Special Considerations for Virtualized and Cloud-based Environments

• As mentioned, some virtualized and cloud-based environments offer remote passphrase entry and varying degrees of passphrase management and automation for full-disk encryption – but be aware that there is often a tradeoff between convenience and security with automated solutions. For example, if a cloud provider keeps your passphrase and automatically provides it to the operating system at boot time, the level of security offered by the full-disk encryption solution is largely dependent on how securely the cloud provider manages the passphrase.

While encrypting data at rest can be a useful component in a data security toolbox, it must be implemented with a full understanding of the protection it does (and does not) provide. Organizations should consult with their vendors, data security staff, system staff, and application staff to determine an appropriate set of actions to secure institutional data.