Archive for the ‘Self-Encrypting Drives’ Category
SELF-ENCRYPTING DRIVES
Let’s look at the software impact of upgrading to Windows 7 and what it can have on Bitlocker. As part of the hardware refresh that can occur associated with these updates the other thing that can happen is people start to look at self-encrypting drive technology (which is becoming more and more available, more and more cost effective).
SED? WHAT’S THAT?
The idea here is the drive is essentially self-defending. So you’ve got a self-encrypting drive, an SED as it’s called. It’s often abbreviated. Usually a fixed disk, which uses some kind of hardware based encryption. The standard for these is OPAL. You’ll see more and more devices that are OPAL compliant. They’re made by people like Hitachi, Toshiba, Seagate and Samsung. So there’s a number of different manufactures now and most of those are moving to some kind of OPAL complaint SED. The Trusted Computing Group estimates that in five years pretty much all drives will have some kind of self-encrypting capability and that includes not just sort of the traditional, mechanical drive but also solid state drives, too. So self-encrypting is really going to become pretty much the foundational element for at least drive based data protection.
HOW IT WORKS
And, you know, there’s a reason for that and it’s conceptually very simple. You have essentially the file system, the operating system running on the drive. In between you sort of, the drive and everything you want to do with it you have a hardware component that perform all encryption tasks. So, typically for SEDs they’re going to be using, again, AES- 128 or 256. So again it’s an industry standard encryption algorithm, but there’s a hardware piece that sits there. Everything that gets written to the drive’s encrypted. Everything that gets read from the drive is unencrypted. There’s a couple of different keys that are used. There’s a data encryption key, and an authentication key. I won’t talk about those in great detail. If you’re interested, a couple of weeks ago we had a webinar just on self-encrypting drive management where I talk in more detail about what those keys do, and where they live and how to manage them and so on.
WHY THE INTEREST?
Many organizations are looking at SEDs. Especially organizations that have looked at software based full disk, or full volume encryption. That approach of encrypting the entire drive is appealing to them. They’re now looking at SEDs, or other hardware based encryption as a way of getting the same kind of conceptual simplicity of encrypts everything, but without a lot of the headaches associated with software based full disk. And, you know, one of the things that, the first things that we hear about when people look at self-encrypting drives is, “Boy they’re really fast.” It is a much faster approach than software based encryption for the full volume because unlike full volume, software based full volume, you don’t have to encrypt everything, but it’s all happening in a specialized piece of hardware. So the drive is essentially running at full speed, and all the encryption’s taking place in specialized hardware. They’re faster to use. They’re also faster to roll out because you don’t have a lot of the upfront work that’s required to prep a system for a software based full disk. Anyone that’s deployed software based full disk knows there’s a lot of work has to go in to ensuring the drive itself, the physical drive is ready to have the encryption deployed to it. And if it’s not ready you can, you know, what’s called brick the system. You can cause the system to become completely unusable. Well that doesn’t happen with a self-encrypting drive. The drive is going to be fine. So you’ve got a lot less work up front, a lot less management, a lot less risk upfront. I think the other thing to say is there’s a lot shorter time to security. Instead of spending a long time encrypting a full volume, in order to get it to “secure” with a self-encrypting drive you pretty much turn it on and it’s ready to go. You’re pretty much security. So you know we’re talking about something in a couple of minutes rather than you know maybe, many, many, many hours. So, faster time, less time, less work upfront, less risk up front. Faster time from a performance perspective and also faster time to security. And it’s just very, very simple. The drive is encrypted all the time. You can’t tell a self-encrypting drive not to encrypt. So you’ve got a very, very simple conceptual and high performance approach. So it’s not surprising that people are looking at SEDs.
WHERE DO THEY FIT?
And again where they fit is the same places you would think a traditional full volume approach would fit. When simplicity’s very important. When, you know, you’re thinking about “well I want to keep the advances of software based full disk encryption without the pain of software based”. And it’s a great place to look at SEDs as part of that hardware refresh. As part of the whole process of cycling through your systems whether it’s every three to four to five years. That’s a great time to start looking at SEDs. But we’ll say that because it’s a full volume approach, just like BitLocker, you don’t get the high degree of granularity of encryption. In other words, I can’t at least currently easily decrypt or encrypt certain parts of the files on an SED. It’s a, everything’s encrypted all the time and therefore when I unlock them they’re usually unencrypted for everything. Again that means that there’s implications if I need to share a system or need to give a system to somebody else and to work on, I can’t just unencrypt the OS and keep the data encrypted. I’ve got to give them an unencrypted everything. And that, again, can be a challenge for sensitive information. Also, I think I will say here it’s probably so obvious it almost doesn’t need saying, yet I’m going to call it out anyway. That you have something else for everything else. In other words, you have an encryption and data protection solution for the other things your data’s going to be going to. Because you know, as data moves increasingly in a large volumes and increasing mobility, it moves on to removable media. It moves on to other devices and out into the cloud and so on. So, SEDs aren’t going to help you there. It’s a device centric form of data protection. It protects that device. And so you’ve got to think well what else am I going to put around it to protect information as that information moves to other platforms to some drives, to mobile devices and so on. Do think about that as part of your planning process.
I think the other thing I will say is that it’s great technology “But” and it’s a big but, right. Deliberately big. And the “but” is like every other piece of data security technology it requires management.
AREAS TO CONSIDER
So, there’s still things to think about even with the simplicity of robustness of a self-encrypting drive. User management, how do I define who has access to that drive and who doesn’t? There’s still questions around key recovery. There’s a preboot authentication step with a self-encrypting drive to unlock the drive. What happens when the user forgets it? How do I do reporting? Defining policies. Integrating those policies with everything else that’s going on in my organization. That preboot authentication step does require the users to understand what they’re doing. Ideally you want to tie the preboot step into [UI] typing my pin so that the drive knows it’s really me. I want to tie in that step with my authentication to active directory generally. So I don’t have to keep re-authenticating as a user just to reduce the impact on me. Remote administration, patching and so on. These are also important things to think about. One of the challenges you’ll have is you still need to have other operational processes. You still need to install software, update software, patch the operating system, and so on. You don’t want to have to physically walk through every system, nor do you want to have users leaving all those systems on 24/7 so that they don’t interfere with your patching process. You ideally want to be able to wake those systems up, unlock the drive, do the patching, relock it all and shut it down again and do it all automatically. And so that’s something you’ll want to consider. Certainly doable with SEDs but it’s definitely something you want to be thinking about, “How do I integrate SED management with the other operational stuff that I need to do as a business so I don’t break everything else I need to get done.”
CREDANT MANGER FOR SELF-ENCRYPTING DRIVES
And if you missed it about two or three weeks ago, we did launch a Credant Manager for Self-Encrypting Drives, which essentially covers a lot of those challenges. So, in other words, it reduces the risk of, reduces the work rather deploying SEDs. It also reduces the risk that will have an impact on your operational processes, such as the patch management. And it more tightly ties everything together from a reporting and policy definition perspective. And ultimately, therefore, it reduces all of sort of the work and the complexity and impact to users, impact to your administrative team, impact to your security teams and so on. So you get the benefit and the simplicity and the performance of SEDs. But you can do it from a centrally managed place with a lot less impact on everything else that’s going on.
INTEGRATING SECURITY
And I have talked a few times and I’m just winding up because I know we’re running close to time on this and I want to make sure I leave time for some questions. I talked a few times about integration here. It’s important to think about integration whether you’re, as you roll out Windows 7, as you think about some of the other options you’ve got for encryption, data protection, integration is important. These stats came from a report from just about a year ago. Eight-eight percent of organizations have multiple administrators managing encryption keys. And part of that reason is there’s a lot to manage. Twenty-two percent have more than ten administrators just managing it, with access to managing encryption keys. That obviously makes it difficult to track who has access to what. And there are multiple encryption suppliers in place, each of which almost certainly has different key management and reporting infrastructures in place which makes it very difficult for you to meet your compliance requirements to prove that everything’s encrypted when it’s supposed to be. And it also increases the risk of gaps in coverage, and that’s a problem. You don’t want to have systems that come on to the network where you may not have rolled them out yet into existing processes because those processes are complicated and manual and time intensive. So you really want to try and simplify a lot of the pieces here.
THE DATA PROTECTION PLATFORM
And I think that’s one of the things that we talked to a lot of organizations about. And sort of as I wind this up, the data protection platform. You know, you think about self-encrypting drives. You think about BitLocker. You think about other devices, removable media. You start thinking about what’s going on with the cloud. The more you can tie those together into a single platform, a single set of tools to manage, define policy, build reports for your auditors, for your stakeholders, for your compliance requirements, that reduces work. it reduces risk and it reduces impact both on the users and on your own folks as well. And that is a huge win. So I will strongly recommend thinking about ways to tie these piece of technology together, and it’s certainly something we would be more than happy to talk to you about if we haven’t already done so.
So, a couple of quick conclusions. I think as you roll out Windows 7, as you think about planning for Windows 7 it is a great time to evaluate what you’ve got in place, and what your options are from a data security perspective. There are a number of new options that you’re going to be looking at, but consistently across all of them, you’re going to see the requirement for management is going to be something that’s not going to go away, and in many ways as the number of options grows that requirement for management really grows with it. So, you’ve got a lot of options, there’s a lot of powerful tools becoming available, but you’ve got to be able to manage them to get the most out of them. And integrating the management of those pieces, tying them all together is what’s going to help you reduce the cost, reduce the workload on you and recue ultimately the risk that you’re going to face breech which you know we all are more than aware of can be both extraordinarily painful and extraordinarily expensive.
THINKING ABOUT UPGRADING?
Many organizations start to think about the process of upgrading to Windows 7 because inherently with Windows 7 there are additions that you might want to make use of. This makes you question integration and the opportunities and challenges it can bring. One of those opportunities might be Windows BitLocker. Organizations with Ultimate and Enterprise editions of Windows 7 should be looking at Windows BitLocker. We’ll examine what the thinking around BitLocker should be, and how to plan and be successful with BitLocker as part of your overall strategy. As you’re upgrading, it’s a great opportunity to look at things like self-encrypting drives. There’s also a lot of buzz around removable media as part of the changed Windows 7, but at the same time, you can think about a broader strategy: Windows, removable media, mobility increasingly, and even cloud services. All of these things are having an impact on the way that enterprise organizations think about data protection.
WHAT IS BITLOCKER?
Let’s cover the highlights of BitLocker. It’s included as part of a number of different versions of Vista. I think it’s fair to say that the version that is now in Windows 7 is definitely an improvement over what was in Vista. Across the various platforms that support Ultimate and Enterprise editions of Windows 7; Windows Server 2008, and 2008 R2. The default encryption of Windows BitLocker is AES with a 128 bit key, a fairly standard encryption.
BITLOCKER OPERATION MODES
It operates in three modes: transparent operation mode, user authentication mode, and USB key mode. The operational modes that you choose for BitLocker will have an impact on the way that you plan to implement Windows 7 as you roll it out. Transparent operation mode is lowest impact as far as your users are concerned. The Trusted Platform Module (TPM), which is a hardware piece embedded in the system, provides what’s called a “root of trust.” When the system boots up it just checks that no one’s been tampering with the system while it was powered down. If it hasn’t, the system starts normally and it’s minimum impact. Transparent operation mode may be attractive from an operation perspective and ideal from a security perspective. User authentication mode requires the user identity pin. It has a pre-boot authentication step where you can set the length of that pin; this is part of the polices you set with BitLocker. Typically, BitLocker is eight digits long, but there is flexibility around that. The third way is to add another layer of authentication is USB key mode, in which you’d have to plug in a USB device in order to boot the system. Most intrusive, and I think it’s fair to say that using the TPM in conjunction with user authentication mode is probably the balance between security and minimizing the impact on users. However, all these things do have an impact because you end up increasing the security of the options you have with BitLocker and increasing the potential impact on the user. You have to keep it up and running and get it configured. And that’s something you want to think about early because management is going to be one of the challenges you want to think about.
BITLOCKER STRENGTHS
It has great encryption, period. Good solid encryption. AES algorithm. You can configure it to 128 or 256 bit key and security that for the volumes that it covers. With full volume encryption solutions it encrypts the entire volume. That’s an impact you’ll want to think about. As I mentioned, it is an improvement over the Vista version. The Windows implementation is considerably better. It uses and AES NI processor support. That’s the Intel chips that will aid processing. And it only utilizes that TPM module. Pretty much all systems these days have a TPM in them. So, it can utilize that TPM and the nice thing about that is that it can add a degree of trust that no one has tampered with the system while it’s been off. The system has the ability to essentially detect if someone’s trying to attack it while it’s offline. The good thing is obviously that it improves security. It does mean, however, that it can have an impact on users if you’re not set up to manage it appropriately. And it will also leverage Active Directory Server 2003 or 2008. If you’re on 2003, you’ll probably require some extensions. It’s all built into Active Directory in 2008 and included in the OS, so for many organizations, the primary reason they’re looking at BitLocker is because it’s already there. It’s included. If you’ve got Windows 7 or if you’re moving to Windows 7 Enterprise or Ultimate editions, BitLocker’s already in there and it’s a fairly compelling argument to say you should at least examine it for some users.
WHERE DOES IT FIT?
BitLocker may, however, not be appropriate for everybody. Like most tools, security tools are no different. They are appropriate for some jobs, and not for others. Obviously, if you’ve got Windows 7 Enterprise or Ultimate, the sensible thing is to at least look at it. For users that do not share systems, then it makes sense because it’s a volume encryption approach. It will require you to unencrypt the entire volume when you turn it on. And as a result the full volume is unlocked and available unencrypted. But unlocked and available for use, across shared systems could be a challenge. Also, it’s for users that don’t have highly sensitive information. The reason I say that is that it’s part of the challenge with a full volume approach once it’s unlocked. If there’s highly sensitive information you might want to think about a slightly more granular approach than a full volume approach. Simply, it may be a fit for some types of users in some environments, but not for others.
CHALLENGES WITH BITLOCKER
Despite the fact that it obviously has very strong encryption, there are some challenges. I’ll be specific about a couple of these because they do have an impact on the way you think about using BitLocker. Recovery key management is one of the more significant challenges with BitLocker as it stands. Recovery keys are required with the TPM. If it senses a threat and goes into recovery mode and you don’t have that recovery key somewhere available for the user, you then have a bunch of users who potentially cannot get into their systems. A system can go into recovery mode for a lot of reasons. If it’s under attack, obviously, but even things like docking and un-docking a laptop can cause the system to go into recovery mode. Also, hitting certain function keys during the boot. If you accidentally touch the wrong function keys during boot time, that can send the system into recovery mode. It can be sensitive. Should you tinker with the way that the TPM’s set up, it can become incredibly sensitive. Bottom line, you’ve got to think about recovery key management. Also, BitLocker by itself really doesn’t provide you much in the way of auditing, logging and reporting that you would expect from an enterprise solution if you’re using multiple, different platforms and different types of users – you’re not going to have that integration either. You’ll probably have to put something else in place for reporting and auditing.
RECOVERY KEY MANAGEMENT
It’s important to understand recovery keys. The question that comes up most is, “What’s a recovery key? My system won’t boot.” The user is already in a great deal of pain at that point. Recovery keys are the things that you create in order to be able to tell that TPM that everything is fine. You only need the recovery key occasionally when the TPM asks for it, but when you need it, you really need it. It’s a 48 digit randomly generated key and you have to type it in using the function keys. You can do a couple of different things with a recovery key, sometimes called a recovery password – they’re essentially the same thing depending on how you store them. But you have to make sure that they’re available, because if it’s 3:00 a.m. my time and the other side of the world someone’s booting a system and it’s gone into recovery mode, you want to make sure you can get them that recovery key so that they can unlock their system and keep working.
RECOVERY KEY MANAGEMENT
You have a few choices when it comes to how you store recovery keys as you create them. You can tell the user to write it down on a piece of paper, but I would not recommend that. (If you wish to go ahead and tell them to do that you certainly can, though.) You can print it out. You can store it on a USB device. That’s when it becomes a sort of recovery key device that you can plug in. Or you can store it natively straight off into active directory. That is an attractive choice from a management perspective. It is not necessarily a great choice from a security perspective, because it will still store in plain text. If it’s in active directory and having the recovery keys available for anyone that has active directory administrative capabilities is not necessarily a good thing, because it means they can then get access to that system. You really have to think about what you can put in place to manage recovery keys and to help mitigate the challenges.
AREAS TO BE AWARE OF
There are some areas to be aware of with BitLocker. We talked about key management and reporting, but FIPS compliance is something else you have to consider as you roll it out. If FIPS compliance is important to you, it will have an impact on the way you configure the policies for BitLocker. You’d have to set it into FIPS compliance mode. Biometric authentication is not supported. There is support for removable media encryption, data security. But it is not necessarily optimal from a performance and reliability perspective; you might want to think about another solution. There are a number of choices when it comes to layering management with BitLocker. Credant as an organization can help you with that. There are choices out there – Microsoft provides a tool called Microsoft BitLocker Administration and Management tool or MBAM, which is part of the Microsoft desktop optimization pack. It is something I would suggest if you’re going to look at BitLocker; you’ll probably end up glancing at MBAM at some point. From an enterprise perspective, it’s probably not something that’s going to meet all of your needs. It certainly doesn’t cover all of the problems. For example, it won’t stop a privileged user or administrator from turning BitLocker off on a system if they don’t like it. But again, you’ll want to look at something to help you manage BitLocker as you roll it out, because otherwise you will find that there will be some significant holes and it’s better to plan for those earlier rather than later.
NEED MORE?
Okay so that’s enough on BitLocker. If you want more information, www.credant.com has a wealth of additional information, including whitepapers and datasheets on best practices for managing BitLocker. Additionally, there are videos of BitLocker management tools. You can actually take a look at the policies you’ll need to set and how to set them, it’s quite helpful.
Stay tuned for part two, where we’ll dive into self-encrypting drives.
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.
There are many inaccurate assumptions on the differences between software and hardware encryption, management and even the benefits. Self-encrypting drives (SEDs) can be an effective tool in your data protection arsenal.
The launch of Credant Manager for Self-Encrypting Drives (part of Credant Enterprise Edition 7.3) was significant in a couple of ways, and it’s something I hear from both inside and outside the organization as our customers start to look at it and make plans to upgrade.
The first is that it recognizes a growing trend in the IT security industry – the re-evaluation of hardware-based encryption like self-encrypting drives (SEDs) as not only a viable choice to keep data secure, but a sensible and economic one too.
SEDs are very powerful tools, but like all security tools they need self-encrypting drive management, and it’s the lack of well integrated and simple to use management tools that has been partly responsible for their relatively slow adoption. Cost was certainly another factor. However it’s clear that as price points for SEDs fall (and more and more systems will be available with SEDs as a standard choice) then the time has come to look closely at what they provide.
One of the great things about SED technology is that it provides the simplicity of full-disk encryption (FDE) without the painful management overhead and user impact of older software-based approaches. SEDs are reliable, fast and far easier to roll out and live with than software FDE. With the publication of the OPAL standard, and the growing number of OPAL compliant devices, the time for SEDs has clearly arrived.
As a result, supporting them and making it easier for our customers to deploy, manage and integrate is an obvious choice for us.
Which brings me to the second reason that this launch was highly significant: it continued the process of building out Credant’s Data Protection Platform approach which we’ve been talking about for some time. The idea is simple – data moves faster than ever, and on more devices than ever, and we are working hard to make sure that information is protected across its full lifecycle. So adding support for this important and growing technology is both obvious and essential.
SEDs are important, and with the right management tool, they can be a lifesaver in the event of a breach – so take a look at what we’re doing with the 7.3 release and let me know what you think.
In the meantime, let me tell you a little more about what we see on the horizon for the Data Protection Platform and why the concept of data lifecycle protection is so important. But that’s for next time!
RSS