Unveiling the Misconceptions Around Self-Encrypting Drives: Part I

SED?  WHAT’S THAT?

A self-encrypting drive (SED) is a disk that has built-in hardware-based encryption.  It’s essentially a drive that is enabled to encrypt all the information that gets written to it and that encryption is done by specialized hardware that has a number of really important and significant implications for how to use it, where to use it, how to manage it and so on. They’re made by a number of manufacturers – Hitachi, Toshiba, Seagate, and Samsung, to name a few. There’s a number of organizations that are drive manufacturers that are building out their capability to supply self-encrypting drives.  And the reason is that they are becoming very, very popular.  Both from the perspective of people wanting to put them in, but also I think from the perspective of organizations looking at them for the first time or maybe coming back and revisiting them.  The Trusted Computing Group, which obviously has something of a vested interest in this space, estimates that within five years pretty much all drives will have some self-encrypting capability built in, and that includes both the traditional disk drives and also solid state drives as well. Sometime over the next few years most of the drives that you encounter are going to be a self-encrypting drive of some kind.

HOW IT WORKS

So, how do they work?  Very simply. Anything that gets written to the drive gets written via a hardware encryption module that encrypts it on its way onto the drive and then decrypts it on the way back.  Pretty straight forward.  Everything’s encrypted. Everything that gets written to the drive is encrypted – the whole thing is encrypted.  It’s encrypted as far as the various standard are concerned – typically AES-128 or AES-256. Pretty industry standard, well-established encryption algorithms as you would expect, meaning the encryption is going to be solid and secure.

Obviously there are a number of caveats and the caveats must always, as they do with any kind of encryption discussion come down to what happens with the keys.  And we’re going to talk about keys, because there’s a couple of keys that are very important when it comes to drives.

WHY THE INTEREST?

Why the interest?  In many cases the reasons we’re seeing organizations look at self-encrypting drive technology are that they’re going through some kind of refresher or they’re re-evaluating their initial deployments or attempted deployments around software based full disk encryption.  They like the idea of full disk encryption, but as I’m sure you know, full disk encryption can have some management challenges. So what we’re seeing is a sort of re-evaluation of the way in which we implement full disk encryption and self-encrypting drives.  They are much faster than software based storage and they’re much more reliable. Data loss is less likely to happen with a self-encrypting drive because they’re much less sensitive to issues around bad sectors.  They also take away a lot of the pain associated with the initial install when people need full disk to be done, defragmenting the drive, checking for bad sectors because some would often be fairly sensitive issues with the drive itself.  In a nutshell, that’s a self-encrypting drive – and they’re simple.

WHERE DO THEY FIT

Where do they fit?  Typically organizations interested in self-encrypting drives are really driven by a couple of things.  One is they want a simple solution, and one that’s simple to live with.  Full disk tends to offer simplicity since everything gets encrypted. Self-encrypting drives are a very simple way to implement encryption in software. Another great feature is that you don’t need to be able to provide different encryption for different types of users.  If you don’t care whether you can save in one go, then again self-encrypting drives are a great approach.  Because it is a full disk, then it’ll be unlocked all in one go rather than being unlocked in different portions for different users.  That’s a consideration you have to have.  And, I think the other thing to think about is fairly self-evident, but self-encrypting drives are only going to encrypt the information that’s on the drive itself.  You will need to think about some information as it moves off the self-encrypting drive technology.  But that being said, if that matches your requirements, then SED’s may be a fit.

OPAL – CONNECTING AND PROTECTING

I want to touch on OPAL really briefly, which is the standard for self-encrypting drive technology.  It is increasingly looked to by the Trusted Computing Group and defines a number of capabilities for self-encrypting drives.  I don’t intend to go through all of them in any great detail, but if you come across OPAL drives then understand that that’s really what the industry is moving to for standards for SED’s. It defines the functions and it defines a lot of the way that these drives will interact with other hardware. OPAL’s an important standard.  And you should expect pretty much all the devices you’re looking at in the future to be OPAL compliant.

COMMON MISCONCEPTIONS

Let’s talk about common misconceptions and areas where there may be some confusion around self-encrypting drives.  We talked a little bit about security for self-encrypting drive, and while that may seem odd, it is an important consideration.  Management and applicability, as in where do you use self-encrypting drives – just where is the right place, exactly?  For one, pre-boot authentication.  If you’ve ever dealt with pre-boot authentication, certainly in the software world, it can have some serious impacts and can be quite a headache to manage.  So let’s talk about what pre-boot authentication can look like for self-encrypting drive technology and about performance, too.  One of the questions that we get a lot is,  “What’s the performance impact if I go to a self-encrypting drive?”

SECURE FROM DAY 1

One of the interesting things about self-encrypting drives is that everything is encrypted all the time.  The entire drive is encrypted.  Everything is encrypted from day one whether you want it to be or not.  It’s not possible to have a self-encrypting drive that isn’t encrypted, which sounds great. The reason is that there are a couple of keys involved.  The first key that you need to know about is the encryption key.  That’s the key that the drive uses to encrypt information and is created when the drive is built; the encryption creates that key.  It is locked away in the hardware.  That’s the key for the encryption of all information saved to the drive and coming back. The problem is that that key is available all the time.  So essentially it’s like having a great system of locks on your front door, but the key is in the door every time you go out.  So you might have great locks, but there’s no security.  That’s where the second key comes in – the authentication key.  The authentication key locks away the data encryption key.  It encrypts it and locks it away so that you can’t get to it unless you have the authentication key that you take with you.  That’s the key that enables you to prove that you are the authorized user of this device and the information.  So, like everything else in encryption, the big challenge is key management. You must secure the authentication key and manage it appropriately.

Now, the good news is that devices are encrypted from day one and there’s no sort of setup.  So the device again is going to be running, encrypting everything as it gets written to the drive itself. What if I need to go and make sure that there’s nothing on there that can’t be found somewhere else.  All you do is destroy the key and the information is unusable.  Once you’ve got that initial key management under control.

THEY DON’T NEED MANAGEMENT

I’m sure you’re asking, “Okay, so how would I do that?”  You do that by putting in management layers and this should not be a great surprise to anybody.  But if you want to be able to manage all of those keys, enable people to get access to their systems without any great difficulty and ensure that they can continue to have access, you need a management layer.  So, there’s technology that enables you to activate the set policies to manage which users have access, when they can have access to remove their right to have access, of course, if you need to.  You really have to think about maintaining control over who has access to authentication keys, and when they need to get access. We have to consider things like user recovery, for when a user inevitably is on the other side of the planet and lost their authentication key and can’t get in.  Things like this are a big challenge when you are looking at encryption technology, especially full disk encryption approaches. One of the big complaints is in the pre-boot step, in other words, the step where the user authenticates himself, if the authentication key is difficult to manage, then it has its own patch management.  People have to literally leave their systems and enable that to happen in the worst case, and that’s really not ideal at all.  You want to question, “Can my management layer maybe enable me to implement while having access to patch management processes?”  System loss is another challenge here. One of the challenges here is if the device is lost, how do I ensure that people can’t have access to it anymore?  Can I kill those keys quickly in order to prevent people from getting in?  This brings up reporting and auditing and wanting to be able to assist them. I want to be able to prove that these controls are in place.  I want to make sure that the information is protected at all times.  Provide auditing and compliance report into my internal stakeholders, my compliance managers and so on. These are the major things that you need to think about when you’re talking about management.

ONE SIZE FITS ALL

One of the other things is to bear in mind is the idea of one size fits all.  SED’s are great and extremely effective.  They are becoming increasingly more affordable as price points are coming down, but they’re still not necessarily going to be the right solution for everything.  Think about the challenges with any full disk approach is that once you unlock it, it is unlocked for good.  For example, if I have sensitive information on my direct device and I need to give it to an administrator or contract organization for them to work on, I need to have that drive unlocked. That could be a concern that they have access to any information that’s on that system. Another option is to provide access to what I would call “non-authorized” users. That’s also something to think about. So they’re great tools, but use them in the right place. There are always things to consider: “What happens when I’m moving onto a different system without an SED on it?  What happens when I move it out into a cloud environment?” They’re a great solution, yes, but you obviously have to think beyond just that device.

Stay tuned as we shift gears to pre-boot authentication and a well-rounded SED solution.