Full disk encryption provides incredible data protection for personal devices.
If you haven’t enabled FileVault on your Mac, Windows Device Encryption on
your PC, or Android Device Encryption on your phone, please go do it now (iOS
encrypts storage by default). It’s easy, efficient, and secure. You will likely
never notice the difference in usage or performance. Seriously. This is a
Once enabled, device encryption prevents just about anyone from accessing device
data. Unless a malefactor possesses both device and authentication credentials,
the data is secure.
Periodically, vulnerabilities arise that allow circumvention of device
encryption, usually by exploiting a bug in a background service. OS vendors tend
to fix such issues quickly, so keep your system up to date. And if you work in
IT, enable full disk encryption on all of your users’ devices and drives. Doing
so greatly reduces the risk of sensitive data exposure via lost or stolen
Servers, however, are another matter.
The point of disk encryption is to prevent data compromise by entities with
physical access to a device. If a governmental or criminal organization takes
possession encrypted storage devices, gaining access to an of the data presents
an immense challenge. Their best bet is to power up the devices and scan their
ports for potentially-vulnerable services to exploit. The OS allows such
services transparent access the file system via automatic decryption. Exploiting
such a service allows access to any data the service can access.
But, law enforcement investigations aside, who bothers
with physical possession? Organizations increasingly rely on cloud providers
with data distributed across multiple servers, perhaps hundreds or thousands,
rendering the idea of physical confiscation nearly meaningless. Besides, when
exfiltration typically relies on service vulnerabilities, why bother taking
possession hardware at all? Just exploit vulnerabilities remotely and leave the
Which brings me to the issue of compliance. I often hear IT professionals assert
that simply encrypting all data at rest satisfies the
responsibility to the security of processing (GDPR Article 32). This
interpretation may be legally correct and relatively
straight-forward to achieve: simply enable [disk encryption], protect the keys
via an appropriate and closely-monitored key management system, and migrate data
to the encrypted file systems.
This level of protection against physical access is absolutely necessary for
protecting sensitive data.
Necessary, but not sufficient.
When was the last time a breach stemmed from physical access to a server? Sure,
some reports in the list of data breaches identify “lost/stolen media” as the
beach method. But we’re talking lost (and unencrypted) laptops and drives. Hacks
(service vulnerability exploits), accidental publishing,
and “poor security” account for the vast majority of breaches. Encryption of
server data at rest addresses none of these issues.
By all means, encrypt data at rest, and for the love of Pete please keep your
systems and services up-to-date with the latest patches. Taking these steps,
along with full network encryption, is essential for protecting sensitive data.
But don’t assume that such steps adequately protect sensitive data, or that
doing so will achieve compliance with GDPR Article 32.
Don’t simply encrypt your disks or databases, declare victory, and go home.
Bear in mind that data protection comes in layers, and those layers correspond
to levels of exploitable vulnerability. Simply addressing the lowest-level
requirements at the data layer does nothing to prevent exposure at higher
levels. Start disk encryption, but then think through how best to protect data
at the application layer, the API layer, and, yes, the human layer, too.