Just to add to the comment below, there are also applications in which the default user file locations are not "my documents" but somewhere in the application directory under "program files". For example, Lotus Notes puts the user's locally replicated email in its directory and so does Palm's HotSync replications.
So in addition to the typical user specific directories and temp directory, you would have to track down each application and encrypt their directories if they have sensitive data. As you can see, things can get complicated. The simple solution would be to secure the entire drive. FDE is not a solution that addresses all the issues related to data security, but when the drive is lost or stolen, it is the best thing to have. Scott On Thu, 21 Jun 2007, Patrick Cahalan wrote: >> 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? > > Don't forget exception modes, even for "savvy" users. People, > for the most part, know that they should take steps to secure > their data, but it's difficult to do manually. > > For example, would you want your enterprise to rely upon manual > *backups*? Savvy sysadmins would know that they had to run the > backups on the appropriate day, archive the media properly, etc. > Bet you dollars to donuts that when the day comes that you need > to restore something from tape, you discover that performing > backups just kept drifting down the priority list... > > With paranoid enough users, there's plenty of solutions out there > (you don't even need to use an encrypting *file system*, just > pgp-encrypt the appropriate files, for example, and you can get > rid of the page file entirely by just adding more RAM to a > machine). The problem is, for almost all groups of users > (including groups of 1), there's members of the group who aren't > paranoid enough. > _______________________________________________ > 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
