Educause Security Discussion mailing list archives
Re: Non-administrator advantages / disadvantages
From: Eric Case <eric () ERICCASE COM>
Date: Sat, 1 Dec 2012 15:50:41 -0700
Eric, I would add remote assistance to your list. It also makes IT more efficient by eliminating travel time. -Eric Eric Case, CISSP ecase (at) email (dot) arizona (dot) edu College of Architecture and Landscape Architecture http://www.linkedin.com/in/ericcase (520) 344-CISO (2476) -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Eric C. Lukens Sent: Friday, November 30, 2012 3:35 PM To: SECURITY () LISTSERV EDUCAUSE EDU Subject: Re: [SECURITY] Non-administrator advantages / disadvantages I find the risks of mildly out-of-date software are still far less than letting the users have admin rights. So just because it takes you a few days to deploy the Java update, doesn't mean that you should give admin rights to end-users so they can have it *today*. Ideally you should get critical updates out within 24 hours, but the lack of admin rights is still more important. If it takes you months to package updates, then you should hand out admin rights to give the users a chance to keep their systems up-to-date. In my previous stint in desktop support at a college at UNI, I found the trick to not handing out admin rights was to make sure nothing ever automatically popped up on the screen asking for them. Once I did that, the number of calls dropped dramatically. You'd still get people asking about installing new software and the occasional settings change, but it became manageable. This means doing the following: 1) Set UAC on Vista and above to silently fail on your end-user's user GPO. The specific setting is "User Account Control: Behavior of the elevation prompt for stand users" and should be set to "No prompt." The "User Account Control: Detect application installations and prompt for elevation" should then be set to disabled. Leave the settings for administrators to whatever you find appropriate. Help-desk staff will need to know to use run as or login as an admin to install/update things. 2) Disable update checking in all applications when packaging them or deploying them. This seems highly counter-intuitive, but as long as you keep up on the notifications yourself and are responsible for installing the updates via GP, SCCM, or whatever else you use, it doesn't really matter since the end-users can't install the update anyway. Usually every application has this setting, though getting it into the package can be difficult. Some applications need to be repackaged, so investments into repackaging software is required to do this right. 3) Disable access to control panel applets that have no settings the users can change. 4) As much as possible, utilize software that does have its own update mechanisms that don't require admin rights. Firefox now has this. If you allow it, Chrome runs from the user's profile, self-updates, and always has up-to-date Flash. 5) Concurrent-software licenses. If possible and if you have concurrent licensing and license managers, install software everywhere you expect it might be needed. While unnecessary software is a risk, I had to balance it against handing out admin rights. 6) Methods for quick deployment. If you have software packaged and a user requests it, make sure you can quickly get it installed on the system. SCCM makes this easy. GP isn't too bad as you tell them to "reboot and it will be installed." Lastly, you still need management backing that certain things are not worth your efforts. For example, I had a user want the power settings on the monitor to never sleep so they could have their slideshow of family pictures for ambiance in their office. You need management to back you up that things not necessary for the person's job are not going to happen or are at least subject to your discretion on implementation. If the philosophy in your institution is that IT will honor every whimsical request even if not related to their job duties, then you just as well hand out the admin rights. Of course, you will have a significant number of users that will rate your performance as terrible for blocking their ability to install whatever they want. However, in my experience, when pressed most of the time you'd find the software had nothing to do with their job responsibilities. If the software was related to their job responsibilities, I generally requested a few days to test it (if I wasn't familiar with it) and would hand the install task over to a trusted student employee. If the software was to be deployed to more than 5 machines or so, I'd package it. Lastly, if the job duties of a person really require constant changing of settings or installation of software, then you should give the user a *second* account with local admin rights to install the software--bonus points if it only works via run-as and can't interactively log on. In those cases, you should set UAC to prompt as usual. The app store in Windows 8 might make some of this problem go away for the "modern" apps. You can per-approve applications and then the users can install them themselves. -Eric -------- Original Message -------- Subject: Re: [SECURITY] Non-administrator advantages / disadvantages From: Shalla, Kevin <kshalla () UIC EDU> To: SECURITY () LISTSERV EDUCAUSE EDU Date: 11/30/2012 3:48 PM
A few have admin rights now, and there's a stampede by others to also get it, so we're considering granting it to many others. Kevin *From:*The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *Steven Alexander *Sent:* Tuesday, November 27, 2012 3:00 PM *To:* SECURITY () LISTSERV EDUCAUSE EDU *Subject:* Re: [SECURITY] Non-administrator advantages / disadvantages Kevin, Most users don't require anything above basic user privilege to do their jobs. If you give them administrator rights, you are giving up control of their machines. The users can install any software, bypass group policy and possibly gain domain admin rights (if a domain admin logs in to their machine). They will also be much more vulnerable to malware. Most malware requires administrator privilege for full functionality because admin rights are needed to install device drivers, put a network card into promiscuous mode or install a new service. Prohibited software can span a pretty wide range: games, P2P software, unlicensed/pirated software, personally owned software. You need to worry about performance/compatibility problems, security issues, copyright. What's the context behind your question? Do your users have admin rights now? Are you considering granting or taking away admin rights for everyone or just some users? Regards, Steven Alexander Jr. Online Education Systems Manager Merced College 3600 M Street Merced, CA 95348-2898 (209) 384-6191 alexander.s () mccd edu <mailto:alexander.s () mccd edu> *From:*The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *Shalla, Kevin *Sent:* Tuesday, November 27, 2012 12:24 PM *To:* SECURITY () LISTSERV EDUCAUSE EDU
<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
*Subject:* [SECURITY] Non-administrator advantages / disadvantages I'm trying to highlight the advantages and disadvantages of prohibiting administrator access for users of Windows computers. Can you provide feedback on what I have below? By the way, what's an example of software that is generally prohibited? Is BitTorrent an example? Is it common? Advantages Most malware stays on one user profile, so other users on same machine are unaffected. Deleting the profile can remove the malware. Prohibited (by policy) software doesn't get installed. Combinations of software known to be problematic are not installed (like multiple active versions of antivirus). Disadvantages User cannot install or update some software immediately - have to wait for desktop support. Kevin Shalla --
-- Eric C. Lukens IT Security Policy and Risk Assessment Analyst ITS-Network Services Curris Business Building 15 University of Northern Iowa Cedar Falls, IA 50614-0121 (319) 273-7434 http://www.uni.edu/elukens/ If you see an attachment called smime.p7s, you may disregard it. It is an S/MIME digital signature file to validate the authenticity of this email message.
Attachment:
smime.p7s
Description:
Current thread:
- Non-administrator advantages / disadvantages Shalla, Kevin (Nov 27)
- Re: Non-administrator advantages / disadvantages Morrow Long (Nov 27)
- Re: Non-administrator advantages / disadvantages Jason Gates (Nov 27)
- Re: Non-administrator advantages / disadvantages Shalla, Kevin (Nov 30)
- Re: Non-administrator advantages / disadvantages randy (Dec 02)
- Re: Non-administrator advantages / disadvantages Steven Alexander (Dec 03)
- Re: Non-administrator advantages / disadvantages Morrow Long (Nov 27)
- Re: Non-administrator advantages / disadvantages Steven Alexander (Nov 27)
- Re: Non-administrator advantages / disadvantages Shalla, Kevin (Nov 30)
- Re: Non-administrator advantages / disadvantages Christopher R Webber (Nov 30)
- Re: Non-administrator advantages / disadvantages Eric C. Lukens (Nov 30)
- Re: Non-administrator advantages / disadvantages Eric Case (Dec 01)
- Re: Non-administrator advantages / disadvantages Shalla, Kevin (Nov 30)
- <Possible follow-ups>
- Re: Non-administrator advantages / disadvantages Geoffrey Steven Nathan (Dec 01)
- Re: Non-administrator advantages / disadvantages Jeff Kell (Dec 01)
- Re: Non-administrator advantages / disadvantages Chuck Braden (Dec 01)
- Re: Non-administrator advantages / disadvantages Harry Hoffman (Dec 01)
- Re: Non-administrator advantages / disadvantages Eric Lukens (Dec 02)