Re: Least User Priviledges for Network Administrators

We're working on some of the things that you mentioned. We already have the
computer use policies, software purchasing policies, security policies, etc.
For reasons that I don't entirely understand (I've only been here 18 months)
that group has historically been able to get away with ignoring such
policies. However, there has recently been a change in upper
management--both within the Network Technology group, and at the top of the
organization as a whole--and the new management team is really driving the
process of tightening down security. So things are changing for the better.

I also have thought about using the Restricted Software group policy, but
there are a couple of hurdles to clear before I can leverage that solution.
The first hurdle was that no one in our organization gets access to group
policies without first completing intermediate level classes on AD and Group
Policy (a sensible quality control measure). I already had the skills, but
I still had to complete the classes to get permissions to start using group
policies, and I just completed those requirements about 3 weeks ago. Since
then, I've been working on getting our AD cleaned up and creating a proper
OU structure that will allow us to really leverage the power of group
policies. Finally, historically, my employer has been mainly a Novell shop
at the enterprise network level (Windows on the desktop) and we use Novell
tools for all of our software distribution, except for Windows patches where
we use WSUS. We have an enterprise policy that requires me to get Group
Policy approved as an accepted enterprise standard for software
distribution, which we are working on. So things are moving in the right
direction, but we do have a little way to go before we can really start
using the Restricted Software group policy. In the mean time, I have run
some software inventory reports using our Novell tools and those reports
have been distributed to each bureau chief, so they've been working on
cleaning up some of the installed software on desktops.

I suspect that you're right about the fact that the users in the Network
Technology group will probably end up having admin rights to local machines.
I have a meeting scheduled for next week with the section supervisors from
that group and some of the employees in the trenches to more clearly define
what they do on a day-to-day basis, and to hopefully find some middle
ground. But honestly, I'm not too hopeful that there will be a middle
ground. I suspect that those users will need to be local admins.

--Tom


"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%2343EG6mFIHA.5544@xxxxxxxxxxxxxxxxxxxxxxx
Looks like I may have over estimated that group. As you mention it sounds
like a big part of the problem has been management so if you have the ears
of the powers that be it would be good to institute computer use policy
that defines specific can and can not with spelled out disciplinary action
possibilities but to be effective the policy needs to be enforced. Such
computer use policies are as essential as computer technical policies.

Again it still may be from very difficult to impossible to have users in
that group not be local administrators due to the nature of their work. An
additional item I want to mention is to look into the user of Software
Restriction Policies to manage what they can run and install on their
computers. Maybe you could have the better disciplined users not that
locked down so that they could try new tools and software that could then
be approved for the rest of the users. Software Restriction Policies can
be enforced for local administrators also BUT local administrators are
exempt from Software Restriction policies while in Safe Mode but the user
most likely would not know that.

Steve


"Thomas M." <NoEmailReplies@xxxxxxxxxx> wrote in message
news:%23KyzyGmFIHA.2004@xxxxxxxxxxxxxxxxxxxxxxx
Sorry for the delay in response. I've been out sick for the last few
days.

While I understand the thrust of your comments, I also believe that one
of your assumptions is at least partially flawed. You stated that the
users in our Network Technology group are most likely, "people that you
already trust." Trust how? Do we trust them to maintain network
equipment? Yes. Do we trust them to observe proper security practices on
the desktop, and to NOT install unlicensed versions of software? No. In
fact, improper desktop security practices and the installation of
unlicensed software occur within our Network Technology group at a rate
that is far beyond that of any other group of users. It is fair to say
that as a group they have a spotty record when it comes to following
enterprise desktop security standards and policies, and they have run
afoul of software licensing requirements. Management is partly to blame
for the situation because until now they have done nothing to crack down
on that kind of behavior. So, in a sense, we don't trust them because
they've proven that a certain level of distrust is appropriate.

That being said, I do not believe that any of them would do anything
malicious, so in that respect we do trust them. The question then
becomes, how do we allow them to do their jobs with the least amount of
disruption and inconvenience, and still insure that desktop security
standards are enforced, and that they're not installing just any old
software that they download from the Internet?

Maybe with XP SP2, that balance just can't be achieved, and if that's the
case then I guess we'll have to live with that fact. At the same time,
my job is to try to find a way to institute the security standards of the
enterprise without crushing their ability to do their jobs. So, I need
to do my due diligence and try to find a creative solution. One example
of a creative solution is what we did with our Web programmers. Some of
their tools do require administrative rights, so we took those tools off
the desktop and moved them to a virtual server. The programmers have
full administrative rights within the virtual environment, but are only
standard users on the desktop. Maybe something similar would work for
our Network Technology group, and maybe not, but these are the kinds of
solutions that I need to consider.

--Tom

"Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23sjYY5fEIHA.5044@xxxxxxxxxxxxxxxxxxxxxxx
While implementing the principle of least privilege is a noble goal I
think you might be over doing it with that group of users. Most likely
they are all highly trained competent people very knowledgeable about
computers and people you already trust as they have access to very
sensitive areas of your network.

Consider the unintended consequences of trying to limit such a group
which could include reduced productivity, missing deadlines, bad for
morale, and they feeling untrusted and incompetent. Also being a local
administrator does not give a user any additional access to the domain
assuming basic best practices for securing the domain are being used..

I am all for PLUP for the average user that will try to install harmful
software on their computer which could even lead to a backdoor to your
network, disable Windows Updates because they read somewhere it would
slow their computer down, change settings they know nothing about,
disable malware protection because they can not access some stupid
website, creating shares so their buddy can access their computer, etc.
All this can greatly impact their productivity and increase IT costs
cleaning up the mess.

Having said that the ways you can increase a regular users access is so
modify access control lists [registry/NTFS], grant permissions to needed
services [can be done via Group Policy], add to privileged groups other
than administrators, and to grant user rights above what regular users
have [via Group Policy]. Unfortunately there are many tasks that simply
can not be granted to a regular user no matter what you try as usually
evidenced by object access failures in the security log when auditing of
object access is enabled. There is not set plan so you will have to do a
ton of trial and error footwork to see if you can accomplish what you
want but I am doubtful it can be done with the needs of your network
technology group. Training users that need administrator access to logon
as a regular user and then use runas when they need admin powers is a
good practice.

http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx --
this may be of interest






.

Relevant Pages

  • RE: [fw-wiz] PIX vs Checkpoint vs Sonicwall vs Netscreen - comme nts?
    ... All NetScreen appliances rely on custom-designed ASICs (Application ... Specific Integrated Circuits) for security policy enforcement. ... supports a finite number of "rules" or "policies". ...
    (Firewall-Wizards)
  • RE: [fw-wiz] PIX vs Checkpoint vs Sonicwall vs Netscreen - comme nts?
    ... All NetScreen appliances rely on custom-designed ASICs (Application ... Specific Integrated Circuits) for security policy enforcement. ... supports a finite number of "rules" or "policies". ...
    (Firewall-Wizards)
  • RE: Mass Distribution of Security Policies
    ... It could start with a Network usage agreement, (Advisory Policy) to all ... Mass Distribution of Security Policies ...
    (Security-Basics)
  • RE: Security Policy-Please help
    ... your Masters in Systems & Network Security, ... Before you begin writing policies, you deffinetly want to make sure you've ... SANS Security Policy Project at http://www.sans.org/resources/policies/. ... L0phtcrack is one of the better tools for testing password ...
    (Security-Basics)
  • Re: Least User Priviledges for Network Administrators
    ... It makes sense to have a chain of command and approval policy to keep things ... the computer use policies, software purchasing policies, security ... upper management--both within the Network Technology group, ... driving the process of tightening down security. ...
    (microsoft.public.windowsxp.security_admin)