I agree with the techncial reasons discussed in this chat and FDE being more compelling the EFS. Why guess when you can be 100%? What about from an end-user perspective? Before responding...I am aware of the common, legacy concerns about FDE solutions affecting the MBR. Mobile Armor has developed a 32-bit vs. 16-bit and our architecture resolves such challenges. With this in mind...are FDE solutions more user friendly then EFS solutions?
Aric Perminter - Mobile Armor LLC. http://www.mobilearmor.com ------------------------------------------------------------------------ ---------- This message may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by erroneous transmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Mobile Armor LLC reserves the right to monitor all e-mail communications through its networks. ------------------------------------------------------------------------ ---------- -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 22, 2007 9:31 AM To: [email protected] Subject: Re: [FDE] compelling reason to do FDE in lieu of EFS? I would highly recommend against using EFS to encrypt a user's entire %userprofile%. Many installation programs (including Microsoft Office) have a lot of issues when you start encrypting the entire %userprofile%. Just to provide an example, Microsoft Office drops a lot of temporary files in the %userprofile% when you run the installation process. Even though the installation runs as your currently logged in user, the installation program will drop these files into the %userprofile% as SYSTEM. Since your %userprofile% is marked as an encrypted folder, these files are then encrypted with SYSTEM's EFS key, meaning your currently logged in user can no longer read them (and the installation fails). This is just one of the many problems I encountered when I worked on deploying EFS to multiple laptops in our environment. We ended up doing a complete roll off and have now implemented a FDE product. Best Regards, Tim Thompson Union Pacific Railroad Information Assurance Engineering "Garrett M. Groff" <[EMAIL PROTECTED] To .com> <[email protected]> Sent by: cc [EMAIL PROTECTED] ml-dev.com Subject [FDE] compelling reason to do FDE in lieu of EFS? 06/21/2007 05:48 PM Please respond to [EMAIL PROTECTED] om For the average standalone machine that is in need of adequate security (but not military grade security), is there a compelling reason to use anything beyond EFS (encrypting file system)? Before you answer, first, let's assume that the EFS user in question understands that he needs to encrypt his %temp% folder (or, better yet, all folders under %userprofile%), in addition to the specific folders to protect that may reside elsewhere in the file system. Let's also assume that he knows to encrypt his page file(s) (and hibernation file, if applicable) as well. Isn't that pretty strong security, assuming Joe Shmoe's password is non-trivial (reasonably long w/ sufficient entropy)? Again, I realize that most users don't know to encrypt %temp% or their page file, but again, for a more savvy user, wouldn't EFS provide a pretty high level of security for data at rest? - Garrett G._______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde . This message and any attachments contain information from Union Pacific which may be confidential and/or privileged. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited by law. If you receive this message in error, please contact the sender immediately and delete the message and any attachments. _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
