Educause Security Discussion mailing list archives
Re: Securing common access computers
From: Michael Sana <msana () HPU EDU>
Date: Wed, 24 Mar 2010 20:57:10 -1000
Aloha, As stated earlier, if you incorporate a thaw space, make sure you set a cron to wipe out any data stored in there at least on a nightly basis. This prevents students’ reliance on keeping their work in there especially when they forget their thumb drives and the file is too cumbersome to email out. It also keeps the malicious scripts from overstaying their welcome. Over the years, the only compelling reason I have found to incorporate a thaw space is for Microsoft Office asd files. When particular office apps crash it hopefully creates an auto recover file, which in many occasions has help save my behind. Whatever the true cause of the crash occurs at the OS or application level, the system may have to reboot. When deepfreeze is enabled, it can be very cumbersome to recover the asd file if the system is unresponsive, so it may turn out that our only choice left is to reboot. Upon reboot all bets are off, the system wipes everything, even the created asd files. As a best practice I would recommend changing the location of your .asd files to point to your thaw space. So imagine the following scenario: your system crashes, an asd file is created and stored in your thaw space, and you are forced to reboot. Upon reboot, MS office will look to your thaw space and provide you the possible recovery options versus it getting wiped out by deepfreeze. Now everyone is happy except for Clippy because he wishes there was a thaw space that existed for him in office 2007. Hope that helps… mike.sana. Michael C. Sana MSIA, CISSP, CISM, CISA Information Security Officer Information Technology Services Division Hawai`i Pacific University 1132 Bishop Street Suite 307 Honolulu, Hawai`i 96813 Telephone: (808) 687-7034 Fax: (808) 544-1425 Email: msana () hpu edu "Quis custodiet ipsos custodes?" ________________________________________ From: The EDUCAUSE Security Constituent Group Listserv [SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of SCHALIP, MICHAEL [mschalip () CNM EDU] Sent: Wednesday, March 24, 2010 5:08 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Securing common access computers Good list - but you also reminded me of another standardization question that I'm coming up against. "Thaw spaces" on academic/instructional computers. Most of our systems do just fine without them - but some computer labs/classrooms *insist* that they are necessary, but I'm not convinced..... Are there applications out there that *really* need a thaw space?......to me, the less persistent space, the less likely you're going to have nasty bits hanging around....?? Any "rules of thumb" or "lessons learned" on this thaw space topic? Thanks.... ________________________________________ From: The EDUCAUSE Security Constituent Group Listserv [SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Michael Sana [msana () HPU EDU] Sent: Wednesday, March 24, 2010 3:46 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Securing common access computers Deep Freeze too for about 10 years now! But let's not forget to implement "defense in depth" strategies... Enable 802.1x if your switch supports it - this helps to prevent users from unplugging and plugging in their own machines... Physically lock the computer down so it's more difficult to be stolen Put a lock on the computer so it's more difficult to steal the hard drive Set the system to boot from hard disk only (or network if you jumped onto the whole VDI bandwagon) so users cant reboot into their favorite linux hacking distro! Set a BIOS password so that they cant go in and change the boot sequence to CD, etc. When creating the deepfreeze seed file, make sure you have the system set to reboot after hours (based on the location) so that no lingering scripts or software continues to "phone home" after hours. This creates a desktop refresh period. If your seed file contains "thaw space", create a windows scheduled task to purge this space hourly, daily/nightly so that no malicious scripts continue to live in there while we are out saving the rest of the world :) Don't think of deep freeze as an anti-virus program Just my quick two cents off the top of my head... mike.sana. Michael C. Sana MSIA, CISSP, CISM, CISA Information Security Officer Information Technology Services Division Hawai`i Pacific University 1132 Bishop St. Suite 307 Honolulu, Hawai`i 96813 Telephone: (808) 687-7034 Fax: (808) 544-1404 Email: msana () hpu edu "Quis custodiet ipsos custodes?" -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of SCHALIP, MICHAEL Sent: Wednesday, March 24, 2010 11:06 AM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Securing common access computers We use DeepFreeze, too.....Are there any other options to this software?.....or is this "the state of the art"? -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Zach Jansen Sent: Wednesday, March 24, 2010 2:39 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Securing common access computers We use a program called Deepfreeze from Faronics to secure the public lab machines from configuration changes. Basically it removes any changes from a machine upon reboot, returning it to the state it was deployed in. The nice thing here is that students can do whatever they want on the machines, such as install software, change settings, and it's removed on reboot. Faronics has a similar program for kiosk type machines, though it has some additional browser lockdown features. We do have individual logins for accountability, except on kiosk machines, and have few problems with misuse. Kiosk machines are more likely to be abused since anyone can use them without a login. Deepfreeze does tend to make investigation harder, though not impossible. Hardware keyloggers are certainly a threat, though I've yet to run into one in my environment. Zach Jansen -- Zach Jansen Information Security Officer Calvin College Phone: 616.526.6776 Fax: 616.526.8550
On 3/24/2010 at 12:08 PM, in message
<EB4A14AA71CE71448233A27D6E0953B101DF98C3392E () SNHU-CCR-A snhu edu>, "Witmer, Robert" <r.witmer () SNHU EDU> wrote:
Even though we require every student to have a laptop computer, historically our organization has provided personal computers in common areas around main campus/remote campuses for students to access specialized software, print papers, access email or their student accounts, etc. I'm wondering how other organizations are securing their common access computers located in pc labs, library, etc. Specifically, from a hardware point of view, does someone inventory every device for hardware key loggers/recording devices? Do you require users to log into the machine for accountability? Do you restrict users from executing programs other than those you've loaded on the pc? Thanks, Bob Please consider the environment before printing this e-mail.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Current thread:
- Re: Securing common access computers, (continued)
- Re: Securing common access computers Zach Jansen (Mar 24)
- Re: Securing common access computers Cal Frye (Mar 24)
- Re: Securing common access computers SCHALIP, MICHAEL (Mar 24)
- Re: Securing common access computers Amber Weishaar (Mar 24)
- Re: Securing common access computers Patrick Goggins (Mar 24)
- Re: Securing common access computers Todd Britton (Mar 24)
- Re: Securing common access computers David Gillett (Mar 24)
- Re: Securing common access computers Terence Ma (Mar 24)
- Re: Securing common access computers Michael Sana (Mar 24)
- Re: Securing common access computers SCHALIP, MICHAEL (Mar 24)
- Re: Securing common access computers Michael Sana (Mar 24)
- Re: Securing common access computers Brewer, Alex D (Mar 25)
- Re: Securing common access computers Witmer, Robert (Mar 25)
- Re: Securing common access computers James R. Pardonek (Mar 25)
- Re: Securing common access computers Zach Jansen (Mar 25)