How Enterprises Can Use Encryption to Protect Linux Servers and Support Compliance Efforts

When it comes to server protection, many enterprises overlook physical security risks. The common myth is that because the servers are in a data center or otherwise behind lock and key, and because the data is in perpetual use, encrypting the drives is unnecessary, as the data is never at rest. 

That’s particularly troublesome. All drives eventually leave the data center for repair or disposal, and having them encrypted is the best way to protect the data from unintentional exposure. And with the enormous number of breaches in the news and compliance regulations – GDPR, HIPAA and California’s Consumer Privacy Act and the like – the prudent advice is to encrypt everything, everywhere, all the time. 

Linux has built in encryption for several years now. So why, then, are enterprises still struggling with their encryption efforts?

To answer this question, let’s review the disk encryption capabilities that are 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 back end.

Together, dm-crypt and LUKS form the basis for a simple “stand-alone,” password-authenticated FDE application; this, however, is not an enterprise-grade solution.

The trouble is, the Linux native FDE leaves gaps in data protection, creating compliance risks. What are some of those gaps?

• No consolidated compliance view of encrypted devices to prove all servers’ encryption states. 
• No centralized password, key management and backup of an encrypted server. 
• Complicated root volume encryption leaving room for mistakes. 
• No easy way to crypto-erase a compromised drive. 

So, the answer as to why enterprises have been struggling with their encryption efforts? It’s due to a lack of management and compliance capabilities built into their Linux servers.

To help address this, organizations should look for solutions that include the following types of functionality and features:

1.     Separation of Encryption and Key Management

To be most effective, an encryption product should be separated into two components: encryption and key management. 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.

2. Robust Authentication

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

3. 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. 

4. An Easy Way to Ensure Root and Data Volume Encryption and Crypto-Erasing of 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.

For enterprises facing potentially crippling penalties for a compliance failure under data protection regulations, having a seamless and integrated encryption solution for servers is essential. With the types of functionality listed above, organizations will be best positioned to pass a compliance audit – and protect the confidential information they hold – should a data breach take place.