SUS/WSUS & Software Restriction Policies

[DJ_Chiro]

Hello all, here's a good one!

I am running SUS and software restriction policies on my domain. Problem
seems that any patches that are approved get downloaded and run from a
randomly generated directory off the C drive. My software restriction
policy is locked down with ONLY the know file paths added to the rules list.
i.e I have c:\program files locked down only allowing certain sub dirs to
run.

I notice the initial file getting blocked is update.exe. I allow this file
to execute only to find another one blocked... I dont want to have to make
exceptions for every file in every future update. Any to make matters even
more fun it seems the folder name where the patches are extracted to is a
randomly generated name that changes EVERY time! Is there any solution for
this? I can't imagine MS not allowing these two great features to not play
nice together!


First error:
Access to c:\eee41c89bfcc5092e94bd7458786c4\update\update.exe has been
restricted by your Administrator by the default software restriction policy
level.

After allowing update.exe I get:
Access to c:\54054a918f273519e2fd8418a7\update\arpidfix.exe has been
restricted by your Administrator by the default software restriction policy
level.

 

[Asher_N]

My first thought is that your policy may be a bit too restrictive.

Anyway, consider moving to WSUS. It deposits all the updates in sub-dirs in
a structure inside the windows dir. You can then have your policy allow
execution of anything under that sub-dir.

 

[DJ_Chiro]

I have it posted in 4 groups... just included them all in this reply.

My users are all local admins so doing that would null the whole policy.

 

[Lawrence Garvin]

I'll throw my .02 in here as well.

The policy is /TOO/ restrictive.

Furthermore, it causes more problems than it can possibly solve.

"Locking down" a workstation to the extent being attempted requires an
in-depth understanding of the operation of various aspects of the operating
system, update methodologies, application installation processes, and a
dozen other elements.

My best suggestion is to /REMOVE/ the policies, and let the system do its
job of protecting itself with the provided security tools.

 

[DJ_Chiro]

You obviously don't understand my environment and the level of security we
require here, the DoD would not take your answer for 1 minute. Thanks for
your .02 but Software Restriction Policies DO work and when setup properly
the machine will run without a problem.

I do understand all the items you have listed (minus the dozen other
"elements") and quite frankly they do not apply. You see, SRP is designed
to prevent a lot of the things you have mentioned. I have my desktops
working fine besides this SUS issue due to the randomly generated folder
name created when a patch is installed. With my in-depth understanding of
the items you listed, I have been able to create a ruleset GPO that allows
the OS to function and the APPROVED apps to run. I have not had a complaint
from not one of my 1200 users which tells me I have implemented SRP
successfully.

I have decided to push forward with WSUS ahead of my plans to rememdy this
situation. Not worth the time trying to work around an issue like this when
SUS is going to be replaced anyway.

Cheers!

 

[Lawrence Garvin]

I know that no organization would impose so much security as to make the
normal operation of the function allegedly being secured /dysfunctional/.

That is, in effect, what you have done by trying to lock down parts of the
filesystem that are designed by the operating system to be used /by/ the
operating system.

You do what you want. You're right, I don't understand it. I don't want to
understand it.

I'm merely pointing out that such efforts will result in much heartbreak and
headache.

As for what the DoD may or may not do... unless your pay grade is higher
than what mine was, I'm fairly confident in knowing what the DoD will or
will not accept in terms of "homegrown" security measures.

 

[Oli Restorick [MVP]]

Hi there

I wonder if allowing all executables signed by Microsoft would be an
acceptable solution. I haven't tested this, but I think it could work.

I find the notion that you allow free administrative access to workstations,
but apply a software restriction policy mildly amusing. What's to stop
these administrators removing or overriding your software restriction policy
locally, and running unauthorised applications? Sure, Group Policy will
place the policy back after (by default) 90 minutes plus or minus 30, but
they can still do it.

Oli

 

[DJ_Chiro]

That is a good idea but I wonder if all MS executables are signed?

As for the other statement, I agree with you 100%. I made that point across
before I was told to go ahead with the implementation. It basically came
down to the fact that if we catch someone circumventing the policy they will
have no "excuses" as to why they are running unauthorized apps. In the past
the regulations always stated strict penalties but nobody acted on them and
the users made up bogus excuses. We are all adults and it is basically a
trust thing and if someone wants to mess around they will suffer the
consequences.

Thanks for your input...

 

[Ken B]

Then logistically, if they're all adults, and it's a trust thing, then you
shouldn't need to place software restriction policies on local admins that
can run a script every 5 minutes to keep your policy settings from applying.
I had one enterprising user who was trusted to have local admin rights
running a script so the screensaver would not engage after 15 minutes. He
lost his local admin rights, and still manages to do his job... just with a
screensaver kicking in.

Just out of curiosity, what sort of 'action' is taken when a user has
unauthorized programs on their computer? At my place, I've 'informed'
directors of people in this case... to no avail. Come back a week later,
heck, a day later and the app is on the computer (again!)... or was it even
removed in the first place?

Ken

 

[JeffG]

"Trust" is a word that should never be used - in any context - in any
security policy. "Trust" is what you rely on when you have no
security policies at all...

 

[Lawrence Garvin]

<VBG>

What an /excellent/ definition of "trust"!

 

[DJ_Chiro]

That is very true and I agree. There needs to be stiffer penalties for user
who violate the rules... If your users are educated about policies then you
can ignore the "I didn't know" answers and seek disciplinary action. We
recently held mandatory expo's that educated our users. This is all part of
the process and it seems that the upper management is going to actually
enforce the penalties for anyone who tries to "work around" the restriction
policy. Only time will tell...

To answer your question about the action taken... It all depends... If I
catch it personally, I uninstall it and tell the user not to do it again...
If I find it again, I tell their supervisor.... If our IDS system picks it
up, for example something trying to access an external server on a specific
port; our network security team files a formal ticket which goes through all
chains of command and eventually gets the user into a sit down meeting...
Lots of paper-work and other politics play into account depending on the
persons status. This part here is going to change I believe since many
people have gotten a slap on the wrist because they are key personnel. Now
that they know they shouldn't be doing this, they should catch a beating...
I guess I'll have to wait and see.

BTW - WSUS working great now!