Comments on: Government should lead transition to self-encrypting drives
Move would enhance the security of private data on federal systems but also help jump-start this tech industry transition, says analyst Jon Oltsik.
Move would enhance the security of private data on federal systems but also help jump-start this tech industry transition, says analyst Jon Oltsik.
Web sites launch all the time, but they also shut their doors. We highlight 15 that bit the dust this year.
Let the debate begin: Was the iPhone more important than iTunes? Was anything bigger than Google finding a great business model? CNET offers its list of the 10 most important stories of the '00s.
Online security is threatened by more than hacking and phishing attempts. Check here for the latest updates on software vulnerabilities, data leaks, and rapidly spreading viruses--and learn how to protect your systems.
Add this feed to your online news reader
TrueCrypt and its kin are a better answer to this problem.
-R
Bonus: If someone DOES hack your system, they'll only find that there's another encryption system that they have to deal with.
Just get them all to use Truecrypt.
It is decently fast, decently secure, free and easily updatable.
I'd trust hardware encryption as much as i trust someone i don't know. (never)
I certainly agree with you that these are the best solution, however, getting self encrypting drives pre-installed in a PC does not remove the need for software licenses and products to manage them nor, as one of your readers says removes the need for key management. That is still there and more critical than ever that it be done properly lest it become the weak link in the chain.
Software is required to not only manage the keys to "UNLOCK" the drive, but as importantly for an enterprise to provide help desk and emergency capabilities that are absolutely essential for any other than individual users, for which, I do agree Truecrypt should be just fine.
Which leads us to the ideal solution which is one that supports both self encrypting drives as well as legacy drives in a totally transparent manner, thus companies can purchase what is best for them and not worry about any differences which. Opal spec or not, variations will always exist as the various vendors fight for turf in this very important battle.
JG Truth In Security
Just an idea..
JG Truth In Security
* how do you enforce password complexity standards? Most encryption schemes ultimately come down to a password. If that password isn't secure, the entire encryption scheme isn't really helping.
* What happens if the user forgets their password, or dies? How can the agency regain access to the hardware and data? Is there a way for the agency to escrow access? [Note: this is not like a back door, because the agency owns the device.]
* If the disk has a partial failure (i.e. bad sectors), does this impact the ability of tools to recover that data?
* servers need to be able to boot unattended. Encryption requires something to be done during boot. How do servers work?
Talking only from an Enterprise point of view here are the answers to each of your very good points:
Enforcing pw complexity is accomplished by/via Active Directory, so whatever a company chooses will be enforced when working with the SED. Of course, if you company does not do a good job they, you will have a very weak link in your security chain.
Most enterprise solutions provide a number methods to recover/unlock an encrypted drive if a user forgets his/her pw, including Help Desks, Administrative overrrides and the archival of emergency recovery information to name a few.
Any failure of the disks behaves not differently than on an unencrypted drive. If a sector goes bad the sector cannot be read and that does not affect the rest of the sectors. This is because each sector is encrypted individually and independently from any other sector
Servers are an entirely different issue but there is an OPAL spec coming out for that as well. Remember that FDE was primarily designed for laptops.
JG Truth In Security
I am well aware that there are answers to many of these points in our existing software-only "data at rest" encryption regime. However, actually implementing these "answers" requires additional software and integration work. The article glosses over this with statements such as "If all new systems contain self-encrypting drives, federal agencies can focus their attention on a stop-gap plan for aging systems in the field." Another statement in this article was "Oh, and self-encrypting drives would also eliminate the systems integration burden as well." The article seems to think that self-encryption drives are a panacea that will instantly solve this problem for new systems. The reality is very different -- federal agencies still need to deal with issues such as enforcing password policies for the drives (remember that they are self-encrypting, so the decryption needs to happen before they boot), escrowing keys, providing a password recovery capability, etc.
Self-encrypting drives are great, but they are not a magic wand that will solve this problem instantaneously.
- by JGTIS March 15, 2009 10:33 AM PDT
- morty_a:
- Like this Reply to this comment
-
(17 Comments)I couldn't agree with you more.
An SED is technically a Self-Encrypting drive, but as you clearly mention, it like a PC must be managed as simply encrypting everything is not a solution in itself.
IMHO, all new systems should be ordered with SEDs and each enterprise or government entity should select appropriate SED management software just like they selection OS's today.
Thank you for a good discussion.
JG Truth In Security