Reasons to limit computer admin rights.

July 2nd, 2009

When I started at UMW, as Director of IT Security in 2007, I had planned to remove computer administrative rights from staff, because they are more likely to access sensitive data, but continue with faculty having full control of their computers. My viewpoint aligned with VITA’s policy as well. Since that time both VITA and I have changed our minds. VITA explicitly removed the faculty exemption in June of 2008. At first I didn’t agree with their decision to limit a professor’s computer access, but now I do.

The Conficker/Downadup worm did a number on UMW, and it is probably still doing damage. Infections spread through departments across sections of  the network. There were over 100 known infections and it took DoIT, myself included, over 3,000 staff hours from mid November 2008 through April 2009 to attempt to clean some of these machines. I used to be very confident in my ability to remove viruses, but this worm is very insidious and it installs various other pieces of malware. Part of Conficker’s business model is to get a fee for each instance of malware it installs for clients. Machines of which I was certain were clean would then be reported by REN-ISAC as still containing malicious code.

Viruses have become more sophisticated. In fact, there is malware that can infect the BIOS which means wiping the drive has no effect. What is the best defense against such an attack? Don’t give it the ability to install in the first place. Anti-virus software alone is not enough because the code writers will just tweak the software until the latest definitions can be bypassed. Not surfing the ‘net or reading e-mail with administrative rights is the best protection, and if only everyone would color within the lines of that limitation.

That being said, I completely agree with UMW’s mission and I do not want to stifle academic freedom, especially being an adjunct for three semesters. I worked on several ways to attempt an alignment between security and convenience. You may have seen this page which allows the Help Desk to remotely do administrative tasks, avoiding the need for someone to make a trip to, or from, George Washington Hall.

Another option that I recommended was virtualization. One could have a virtual machine to use as a sandbox and have complete admin rights to it. An argument against that was “Couldn’t that still allow an infected machine on the network?”, and the answer is “Yes”. However, a virtual machine would not be a ‘member’ of the network and should not have the same access to sensitive resources, such as Banner, as a domain machine, and passwords on the VM should not match production passwords. VMs don’t usually run all the time and are often shut down reducing the spread of infection. Infected VMs are easier to replace than infected hardware and the non-physical BIOS can easily be cleaned.

Virtual machine snapshots allow one to return the VM to a known state. I use this technique when research, as a certified ethical hacker, is likely to take me to malicious sites. When done I revert to the previous point and all changes in the VM, including malware, are completely removed. If teaching a class, and encountering an obstacle requiring admin rights, a professor could install the needed application into a virtual machine, that is if assistance from DoIT was not readily available. Faculty at CGPS do not have local admin rights on any of the lab/classroom machines and virtualzation is used often by both students and professors.

The ‘admin rights for faculty compromise’ that DoIT came up with was to create local admin accounts for those requesting such access and demonstrating a need for this capability. This compromise is still a violation of VITA policy, but an exception could be made.  However, my experience has seen little understanding from that organization. Anyway, a local admin account could be used with RunAs to launch programs in the context of a computer administrator. A technique I used for years at the State Dept. was to run a CMD prompt as an admin and programs launched from that window would inherit the needed privileges. I was able to work around every perceived need to ‘log in’ as that account and only used the credentials within the context of my ‘regular user’ login. Web browsers can be launched temporarily solely for the purposes of installing plugins and extensions, for example.

Members of the UMW community have had personal credit card numbers stolen by ‘web browser hijackers’ and fraudulent purchases have been made, even as far away as Mexico. If UMW continues to follow the pre-2008 local admin policy then it is only a matter of time before significant quantities of personal information are compromised.

The decision to remove local admin rights is not a ‘control’ issue, it is a safety precaution.  There was once a time when many of us didn’t have anti-lock brakes, air bags, or even seat belts in our cars, but now we want them, expect them, for our safety and the protection of those riding in our vehicles.  Not using a computer as a local administrator helps protect not only our own computer and data, but also those using the network along with us.


css.php