In the past, I have tried to make the case for encrypting physical servers on premises.  The argument for not needing to encrypt them is that these servers usually run for weeks, months, or even years without being brought down. And, that they are physically protected within a well-fortified data center.  The protection that Full Drive Encryption (FDE) brings only really applies to data at rest, and it seldom is at rest on these servers.

The Need:

Countering that argument, I offer that all drives eventually leave the data center for repair or disposal, and having them encrypted protects you from having your old drives show up on eBay –  with your customer data still on them.  Encrypting the drive means it can be quickly and easily crypto-erased if it is still operational, and if not, the data is still not accessible without the encryption key.

That was the past.  Now, with the enormous number of breaches in the news and de facto global standards like GDPR and California’s Consumer Privacy Act, the prudent advice is to encrypt everything, everywhere, all the time.

When it comes to Linux Servers, Linux has built in encryption for several years now, yet enterprises still struggle with encryption on Linux servers.  Why is that? To answer this question, let’s first review the disk encryption capabilities that are built into Linux:

1. dm-crypt (https://en.wikipedia.org/wiki/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 FDE (Full Disk Encryption).  The actual encryption is not built into dm-crypt, but rather it utilizes cryptographic routines (e.g.  AES)  from the kernel’s Crypto API.
2. LUKS (https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup)
   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 basis for a simple “standalone” password authenticated FDE application; this, however, is not an enterprise grade solution esp for servers where it is very inconvenient to have to have an admin present to type in a phase phrase at boot time. (Read more about the scenarios, advantage and disadvantages of native Linux FDE at https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system)

In discussions with our customers, here is what they’ve told us they require for their data-at-rest protection for Linux – which they could not get from dm-crypt and LUKs alone:

1. Centralized Compliance view of encrypted devices:  The ability to go to a console to see if a Linux server in their organization is encrypted and compliant with their encryption policy. The server communicates its encryption status (for all disks) to the central console on a configured time interval. Thereby, if a server goes missing, the IT department would have proof of its encryption state for the auditors.
2. Centralized password & key management of encrypted server: Overall password recovery, operations & management of the 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 info.
3. Secure Network Unlock (Automatic boot):  The ability to boot without an admin present.  Leverage pre-boot networking to connect to a policy server to obtain keys for startup without compromising the security of encryption keys and data.
4. Initial Online Encryption: Have the ability to encrypt pre-installed Linux servers without having to back-up data up, wipe the disk and re-install Linux with encryption enabled.  No need to take existing servers offline to encrypt them.
5. Root Volume Encryption:  Root volume encryption, data volume encryption and encrypting swap partition are all needed, however protecting the root volume with Linux native FDE is generally quite convoluted thus necessitating an improved mechanism.
6. Crypto-erasing a comprised drive: Having 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.AND
7. Having the ability to manage all the above for any device, regardless of the OS (Linux servers,Linux desktops or laptops, Windows servers, desktops, and laptops, and macOS laptops too) – all from a single console, because they dread deploying a different management solution for each OS type.

The Solution:

This is where our new SecureDoc for Linux comes in – SecureDoc for Linux for physical servers is a close relative to SecureDoc CloudVM for Linux for virtualized machines.  It builds on the capabilities available in Linux (such as dm-crypt), and adds a layer of manageability that scales at an enterprise level.  So to answer the question I posed at the beginning of this blog, “Enterprises still struggle with encryption on Linux servers. Why is that?”, the answer is quite simple – enterprises have been struggling because of a lack of management and compliance capabilities available in their current solution sets.

For example, here is a comparison table of the feature capabilities of LUKS disk encryption vs SecureDoc for Linux:

It is still in the early days but, in conjunction with our central SES encryption management server, we can already do everything on the list above.  If you would like to learn more or perform an evaluation, please contact us at info@winmagic.com