Are Your Linux Servers Really Protected?

It’s often thought that because the servers are behind lock and key and/or in a data center, and because the data is in continuous use, encrypting the server drives isn’t needed since the data is never at-rest.

• By Garry McCracken
• Jun 12, 2019

When thinking about IT security, one area that may not readily come to mind is the physical security of an enterprise’s servers. It’s often thought that because the servers are behind lock and key and/or in a data center, and because the data is in continuous use, encrypting the server drives isn’t needed since the data is never at-rest.

That thinking presents a significant potential problem, though. Eventually, all drives need to be repaired or disposed of and must leave the data center. Having them encrypted is the best way to protect the data on them from accidental – or potentially not accidental – exposure. Adding to that, given the seemingly never-ending amount of breaches in the news and compliance regulations like GDPR, HIPAA and those of all 50 states, the wise advice is to encrypt everything, everywhere, all the time.

If you have Linux servers, you may think you are protected since Linux has built in encryption for several years now. But, that may not in fact be the case. Why is that?

Following are the disk encryption capabilities built into Linux:

dm-crypt

dm-crypt is a transparent disk encryption subsystem within the Linux kernel. It is a block device-based abstraction that can be inserted on top of other block devices, like disks. It is, therefore, an ideal technology to be used for full disk encryption (FDE). The actual encryption is not built into dm-crypt, but rather it utilizes cryptographic routines (e.g., AES) from the kernel’s Crypto API.

LUKS

LUKS (Linux Unified Key Setup) is a disk encryption specification that details a platform-independent standard on-disk format for use in various tools (e.g., a standard encryption header), which provides the basis for implementing password management. LUKS operates on Linux and is based on an enhanced version of cryptsetup that uses dm-crypt as the disk encryption backend.

Together, dm-crypt and LUKS form the foundation for a simple, “standalone” password authenticated FDE application. However, this is not an enterprise grade solution.

The problem is, the Linux native FDE leaves gaps in data protection, including:

• No centralized password, key management and backup of an encrypted server.

• Difficult root volume encryption leaving room for errors.

• No straightforward way to crypto-erase a comprised drive.

• No consolidated compliance view of encrypted devices to prove all servers’ encryption states.

The lack of management and compliance capabilities built into Linux servers have caused enterprises to struggle with their encryption and data protection efforts.

So how can businesses with Linux servers best address this? They should look for solutions that contain the following features and functionality:

Separation of Encryption and Key Management

To be most effective, an encryption product should be separated into two components – encryption and key management -- because the expertise to deliver these two components is quite different. For extra protection, consider solutions that layer on top of dm-crypt rather than replacing it to better cohesively manage encryption.

Robust Authentication

With so much focus today on identity and access control, it’s important to have an encryption solution that can provide more robust authentication of servers to ensure that your data is safe from harm. Pre-boot network-based authentication can provide this, bolstering security before the operating system boots.

Simple Way to Ensure Root and Data Volume Encryption and Crypto-Erase a Compromised Drive

Root volume encryption, data volume encryption and encrypting swap partition are all needed for security and compliance. Look for solutions that enable this in a simple manner. Also, the solutions should have a simple mechanism to cryptographically erase all data when a drive is compromised, or it is to be repurposed. This operation must also be recorded for compliance reasons.

Centralized Compliance View and Management of Encrypted Devices, Keys and Recovery Information

With this type of visibility, you can see if a Linux server in your organization is encrypted and compliant with your encryption policy. The server would communicate its encryption status (for all disks) to a central console. Thereby, if a server goes missing, the IT department would have proof of its encryption state for auditors. Also, overall password recovery, operations and management of an encrypted Linux server from a central console is essential. The console should also be able to provide central backup of the encryption keys and recovery information.

Having a seamless and integrated encryption solution for servers, including for Linux servers, is essential. With the types of functionality listed above, organizations will be best positioned to protect the confidential information they hold – and meet the requirements of the ever-growing list of compliance regulations – should a data breach take place.