Data-At-Rest Encryption

To encrypt or not to encrypt?  That is the question.  The answer is universally YES!  However, there are two schools of thought when it comes to protecting data at rest (possibly more, but I only care about two).  First of all, let’s define what data at rest (DAR) is so you don’t have to open a new tabbrowser window and hit Google.  I’m sure if this post has come up on a search or has otherwise caught your eye you know what DAR is, but I’ll lay it out for you here nonetheless:   Any data that is not traveling over a network, or is sitting in volatile memory is DAR.  It’s sitting somewhere in storage, hoping to be useful someday.  This could be any data, from old emails to operating system files to cached logon credentials.  Whether or not you feel like you are a target for malicious computer users, you should want to protect your data.  More so if you’re an organization that deals with proprietary data or government information.

Now, back to the two schools of thought:  on the one hand you have File Encryption (FES), on the other Full Disk Encryption (FDE).  Both technologies have their pros and cons, and both have their vehement supporters and nay sayers.  I’d be interested to know what your thoughts are on the matter.  I myself have an opinion, and it is just that—an opinion.  I won’t say that it fits every scenario, but for security centric folks I’d say that FDE provides the most robust security for mobile devices and fixed workstations alike.  That view is not shocking; most experts will agree that FDE’s preboot authentication, which negates the extremely lax and easily bypassed security of BIOS and operating system (OS) passwords, is a highly secure method of protection.  Let’s not forget that FDE prevents the hard disk or the OS from being accessed via a live Linux distribution, such as BackTrack. Once a malicious user has physical access to a device, compromising it can take seconds with a live boot Linux OS like BackTrack; however, if the device is protected by FDE then the OS and the data is unreachable.

Some pundits argue that FDE is cumbersome to the end user and has a low level of acceptance when it is deployed.  Speaking of deployment, others say it is very difficult to deploy FDE software in an enterprise environment.  I can speak to both of those issues:  First, depending on the skill level of the IT staff, it is not difficult to integrate FDE software en masse using directory services or other management platforms.  As far as end user acceptance, the grim picture that has been painted by some is that of a painstaking logon process followed by a horrendously long boot cycle.  This in fact is false.  Most FDE software integrates with the native OS’s logon daemons or services such that it is nearly identical to the logon process the user is familiar with.

File Encryption has its place. FES is most suitable for non-mobile devices, protecting critical data or OS files. Even then, it takes a lot more configuration and monitoring to ensure that you cover all of your bases. And, sometimes companies leave it in the end user’s hands to decide what’s encrypted and what’s not. When it comes to security my rule is to NEVER leave it to the end user. Also, if you give someone an inch, they’ll take a mile. FES leaves the door open for attackers to be able to access the OS and unencrypted portion of the file system. Maybe they’ll drop a few links in a non-critical area, or perhaps they’ll slip a few custom dll’s into a non-encrypted area of the file system, just waiting to be called by a cron job. If you’re going to invest in DAR, why would you give malicious users a foothold?

FDE has come a long way and has had its ups and downs, but for the most part I feel it is the most secure solution for a mobile workforce (heck, if it works on laptops why not workstations?). All of the stars need to align properly for a successful FDE implementation: first, you need upper echelon support; second, you need a skilled technical staff to implement it, and third, you need to communicate its benefits to managers and users alike.