Garrett M. Groff wrote: > Yes, good point. FDE doesn't by itself address all of an organization's > security needs. In regards to the online attack scenario that you describe > below (running ecard.exe, an attachment, while logged in as administrator), > several things come to mind: why is the user logged in as admin, in clear > violation of the principle of least priv? Does the machine have antivirus > software installed? Why would anyone in his or her right mind run an > attachment? Also, shouldn't a policy be in place to prevent executable > attachments so that less-than-savvy users won't run them by accident?
In the ideal environment these things would not happen but in .edu land, you see all kinds of craziness. > > Conclusion: online attack scenarios are not prevented by FDE. But that makes > sense, since the intent of FDE is to protect the data on the machine from > offline attacks that bypass the operating system's standard login and > authentication mechanism. For online attacks, other measures are useful, > like principle of least priv, security software, local/domain policies that > afford a higher level of security, etc. Hence, it makes sense to use FDE *in > addition* to the other "good security practices" that have been heavily > documented elsewhere. > > - Garrett > > >> 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. >> > > _______________________________________________ > 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
