Re: Peeling off desktop Administrator Rights

["Flynn, Gerald" <flynngn () JMU EDU>]

> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of randy marchany
> Sent: Monday, December 07, 2009 5:43 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Peeling off desktop Administrator Rights
>
> It's been very interesting to see the different scenarios that you
> guys have for delegating some priv set to general users. But, IMHO,
> all of these don't address the real issue: how long does it take for a
> general user to get a software package installed on their desktop if
> you don't allow them to do it themselves? Hours? Days? Weeks?

Whatever it takes for point, click, and install in any of the
following cases:

- if it's an SMS advertised package
- if it's a BeyondTrust enabled package
- if it's an install in the BeyondTrust folder
- if the user knows their admin account password they can either RUNAS,
  logout/login as their admin account, or elevate their regular
  domain account by placing it in the administrator's group. This is the
  least desirable option and we are working on the other options to make
  it less necessary

A little longer if they need help and the HelpDesk or College/Departmental
technology coordinators need to get involved. But this is less of a
technical limitation than a teaching or resource limitation.


> As a long time sysadmin (25+ years) I've beginning to think that we
> (sysadmins) are more of the problem than the users because we set up
> environments that make address OUR needs/likes and not so much the
> user requirements.

I'd disagree. I say we're trying to alter the environment to be more 
resilient in the face of constantly defective products, compromised 
legitimate web sites and services, interconnected systems open to 
abuse, and sophisticated criminal attacks while our end user devices 
are used to access more and more sensitive and constituent data.

> That model dooms a site to failure, I think.  The
> "original" purpose of these restrictions was to prevent users from
> downloading malware/trojans  that were embedded in "cute" programs
> like aquarium backgrounds, etc. So, the sysadmin in me says "no, no,
> no, you can't do that" but we never built an efficient mechanism to
> allow a user to download what THEY need to do THEIR job.  I know one
> of the reasons why I went down this path was because there was only 1
> of me and 10K users. 2 events would overwhelm my response
> capabilities. The attack vectors have changed. Now, malware gets
> inserted on a desktop without any active user intervention other than
> surfing the www and having malware downloaded to their desktop which
> is the very thing we tried to prevent with our "no local admin
> rights".

A least privilege account can limit the damage exploit payload
can do. If the payload assumes administrator privileges, running
in a least privilege account may keep it from doing anything.

Also, many infections are still due to the same old operator
installed malware problem, not drive-by attacks. Not so much 
from cute programs as from well engineered attacks scaring or 
otherwise motivating operators into installing fake anti-virus 
software, fake video codecs, and/or fake updates.

> So, are we going to ban www surfing? Doesn't that impact the
> business process? 

Depends where I'm surfing and what my job function is. :)

> Imagine if we sysadmins aren't allowed to surf sites
> like sourceforge, packetstormsecurity, etc. If that happens, then our
> job becomes much more difficult.
>
>  I look at some depts here on campus who let their users install
> whatever software they want and I don't see any significant increase
> in bad events happening in those environments. This leads to me
> question how effective was the user ban?
>
> That's why I'm curious to see how long it takes from the time a user
> requests a software package to be installed on their desktop to the
> time it actually gets installed. I think you'll see what I'm talking
> about when we look at the responses.
>
> -r.