Garrett M. Groff wrote: > Using an FDE solution on the primary drive (on which the OS is installed) > would resolve the problem of temporary files, paging files, and the > hibernation file since the data in those files (and all other files on the > disk) will be encrypted. Any secondary drives should also be encrypted if > they contain confidential data. Further, removable drives and USB > solid-state devices can be encrypted (probably with the same FDE solution > used to encrypt the primary drive). Hence, any data written to those devices > is also encrypted, affording a high level of security. >
To my understanding, FDE is good for data at rest when machine is off. Once the system is booted, my understanding is that any legitimate user then has access to the data (inasmuch as the OS allows it via auth) and this means someone foolishly clicking on ecard.exe might get the Storm worm if circumstances are right (running as Administrator, etc). What good is FDE in this case? From what I can see, FDE does not meet this particular need. For a system that's been physically stolen (and powered off), FDE seems like a good solution. But protecting the data while the system in use seems like a different challenge. We've seen messages here about using encrypted virtual volumes for this, which would cover things stored in that volume when the volume is not unlocked. If the user has to have data open all day long and there is an attack surface through that user, then that data is also at risk. I don't see any good encryption solution for this. If the user can see the data, so can the malware, to the best of my knowledge. I need to do some more research, but that will probably have to wait until I return from BlackHat. > > ----- Original Message ----- > From: "Curt Wilson" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, July 23, 2007 10:51 AM > Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use > > >>>> This means two things: ... save only the encrypted files long term, >>>>> AND use a full disk file scrubbing utility >>>>> religiously, to get rid of all of the temp files and other garbage as >>>>> quickly as possible. >>> Encrypted virtual partitions automatically accomplish the first of >>> these and obviate the need for the second. >>> >> I appreciate the discussion however this last message appears to gloss >> over some details, or perhaps I just don't understand deeply enough. >> >> How exactly does an encrypted virtual partition obviate the need for the >> second ("get rid of temp files")? Doesn't Windows and various Windows >> apps stash temp files in the various "Documents and Settings" (XP), and >> "Users" directories? And also stash items in the page file? Do you >> suggest encrypting the page file within an encrypted virtual partition? >> How about the hibernation file? Clearing the pagefile at shutdown works, >> and protects against a "data at rest" attack, but what about while the >> OS is running and in-use? >> >> Perhaps there is a way to protect the data with encrypted virtual >> partitions but how does it address these particular concerns? Perhaps >> Windows, and every app, could be tweaked to use some environment vars >> for temp location (maybe this is already done) and we could modify that >> location to be within the encrypted virtual partition. We might then >> have to activate the encrypted virtual partition at boot, in case the OS >> wants to also use that space and can't find it because it's not yet >> decrypted. Perhaps that's where a hardware token would come into play >> post-boot, pre-login? >> >> Clearly FDE has it's place for protecting data at rest. >> >> If vendors are going to respond to me privately, please address these >> questions specifically. Thanks >> >> Have a great day >> >> >> >> >> Mike Markowitz wrote: >>> Bob: I quite enjoyed your last note... sounds like it'll be an worthwhile >>> talk. I'd like to see you add one idea, though... >>> >>> At 01:33 PM 7/20/2007, Robert Jueneman wrote: >>>> FDE is probably the only solution for the Data at Rest >>>> problem that everyone is currently focused on, i.e., when the computer >>>> is turned off. >>> Not quite: encryption of a virtual disk containing all sensitive data >>> on the system would also work. (There are good reasons NOT to encrypt the >>> OS and program files.) >>> >>>> make sure that there is NO plaintext exposed >>>> on the computer for any longer than is absolutely necessary. >>> Exactly the reason to use an encrypted virtual partition with a device >>> driver that only presents plaintext to applications (running under an >>> authorized user's login process) *via RAM* and ensures that only >>> ciphertext is written to disk. You simply 'mount' the partition when >>> you need access to the data and 'unmount' it when you're finished. >>> (If you're really clever, you automate the mounting and unmounting >>> processes, possibly with integrated user authentication.) >>> >>>> This means two things: ... save only the encrypted files long term, >>>> AND use a full disk file scrubbing utility >>>> religiously, to get rid of all of the temp files and other garbage as >>>> quickly as possible. >>> Encrypted virtual partitions automatically accomplish the first of >>> these and obviate the need for the second. >>> >>>> [with regard to file encryption] Unfortunately, really large files can >>>> become rather cumbersome to deal with, and particularly the .pst files >>>> created by Outlook - some of which can grow to 4 GB. >>> Bob, I love you! This is the BEST reason to use a device driver that >>> performs application-transparent decryption 'on the fly' for all *block* >>> reads (by authorized applications), and encryption for block writes. >>> This way there's never any need to need decrypt an entire file. >>> >>> Always happy to see you motivating the adoption and use of our products! >>> >>> Regards, >>> >>> -mjm >>> >>> _______________________________________________ >>> FDE mailing list >>> [email protected] >>> http://www.xml-dev.com/mailman/listinfo/fde >>> >> >> -- >> Curt Wilson >> IT Network Security Officer >> Southern Illinois University Carbondale >> 618-453-6237 >> >> GnuPG key: http://www.infotech.siu.edu/security/curtw.pub.asc >> >> _______________________________________________ >> 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 > -- Curt Wilson IT Network Security Officer Southern Illinois University Carbondale 618-453-6237 GnuPG key: http://www.infotech.siu.edu/security/curtw.pub.asc _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
