I'm going to have to respectfully disagree somewhat with Simson. > You simply cannot assure that a drive will be physically wiped. If > the drive will not be physically destroyed at the end of its life --- > and it is hard to assure that a drive will be physically destroyed > --- the drive should be encrypted with FDE.
While it's true that there are millions of examples of bad data security policy, that doesn't mean that FDE "makes your problems go away". You cannot rely on hardware or software to solve your security problems; all you can do is implement mitigation efforts. Simson didn't precisely say this in the above paragraph, but there's a lot of absolutes in that one paragraph and there's hardly ever any absolutes in the real world. Certainly, you can't have 100% confidence (regardless of your process) that every drive will be forensically zeroed out. You can't have 100% confidence that every drive will be shredded. You also can't have 100% confidence that some beanhead in your data center will use a P-touch to put the FDE boot password on the exterior of your file server, right next to the IP address, MAC address, and root password in violation of your security policy, either. You should take the mitigation steps that make the most sense in your organization, given the value of the data that you're trying to protect (both internally to your organization and externally, because as a professional you have an ethical if not legal obligation to protect your customers). IME, 95% of the time the most efficient solution is *not to store the sensitive data in the first place*. The remaining 5% of the time, a combination of software, hardware, and human processes are going to be required to properly protect your data. FDE has a place in that equation, but it's just a part of the overall picture. _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde
