[gptalk] Re: Office Blockage...
- From: "Michael Pietrzak" <mpietrzak@xxxxxxxxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Wed, 23 Jul 2008 11:01:33 -0700
I am a current user of the Parity product from Bit9. Works great! But as
Darren points out, application whitelisting\blacklisting is VERY hard to
do. It's no wonder there are very few players in this market out there
now. BUT, once you get it in place, and get everything working as you
like, it works like a champ. I have effectively kept all crap off my
workstations and that goes for machines where the users run as admin. I
even retired our old crappy anti-spyware app since moving to Parity from
Bit9.
If you want to know more about the product, I'd be happy to help you out
but it does require a lot of patience at first.
Michael P.
San Diego State University
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
On Behalf Of Darren Mar-Elia
Sent: Wednesday, July 23, 2008 10:59 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Office Blockage...
Deepu-
You will be hard pressed to find a perfect solution for every scenario
you
have. Security is a combination of elements. You need to ensure first
that
users are not administrators on their workstations. Next, you need to
ensure
that the file system and registry are as secure as possible, so that it
is
difficult for the user to move things around or change things to their
liking. Finally, you need to control what code is installed and run on a
system. Each of these lines of defense requires a fair bit of work and
even
then, if your users need to run a lot of applications as a function of
their
job, you will find it hard to reach your goal.
But, for the purposes of this discussion, let's try to get you closer.
First
off, is cmd.exe allowed to run? If not, then scripts won't run. Also,
when
you create SRP policy, MS adds some default registry path rules that
basically allow core Windows components and anything in Program Files to
run. Did you leave those rules in place or delete them?
If you want to control what the user can run, but, as you say below,
"it's
not feasible to block all exe's as user may have to install some files
or
they may need some exe to run externally..." then you are cross-purposes
to
your goal. If the user can install code willy-nilly and that's ok, then
you
will never be able to successfully control what they can do.
At this point, you might want to look into 3rd party products that
perhaps
have more flexibility than SRP. For example, while I haven't used it, I
know
that Bit9 (www.bit9.com) helps in this area.
Darren
-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
On
Behalf Of Deepu
Sent: Wednesday, July 23, 2008 10:47 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Office Blockage...
Hi Darren,
Even after removing the vbs and cmd extension. We can't run cmd
files.
Let's assume even if starts working. it's not feasible to block
all exe's as user may have to install some files or they may need
some exe to run externally...
So using this method will be a problem for us...
Also let me know why the script is not running even after removing
the cmd and vbs extension...
Thx...
On Wed, 23 Jul 2008 Deepu wrote :
>Hi Darren,
>
>I have even tried the whitelist mode. But doing so blocks all exe
>and even it doesn't allow to run vbs (scripts) which are
>necessary to run.
>
>There may be some exe's which user should run.. So, allowing this
>policy doesnot works...
>
>Thanks...
>
>------------------------------------------------------
>
>On Wed, 23 Jul 2008 Darren Mar-Elia wrote :
>>Deepak-
>>Have you considered using Software Restriction Policy in
>>whitelist mode?
>>That is, set the default level to disallowed and then only allow
>>a specified
>>pre-approved set of executables?
>>
>>Darren
>>
>>-----Original Message-----
>> From: gptalk-bounce@xxxxxxxxxxxxx
>>[mailto:gptalk-bounce@xxxxxxxxxxxxx] On
>>Behalf Of Deepu
>>Sent: Wednesday, July 23, 2008 7:39 AM
>>To: gptalk@xxxxxxxxxxxxx
>>Subject: [gptalk] Office Blockage...
>>
>>Hi Friends,
>>
>>I am in a great problem. I would really appreciate if anyone
>>can
>>help me at the earliest:
>>
>>Problem: I want to block some executables like access.exe,
>>publisher.exe and communicator.exe using group policy.
>>
>>Now the problem is i can't use Software Restriction Policy
>>using
>>hash rule as the hash will change everytime microsoft patches
>>or
>>release service pack for office 2007.
>>
>>Secondly if i use Software Restriction Policy using path rule.
>>The
>>user can simply copy the exe to alternate location and can run
>>the
>>program with ease.
>>
>>So,i would really appreciate if anyone can help me to solve
>>this
>>issue, as the user can't open the above mentioned exe from
>>anywhere. I want to implement it using group policy. A custom
>>ADM/ADMX will also work... Please guide me if possible...
>>
>>Waiting for your reply...
>>Deepak Kumar...
>>India...
>>
>>***********************
>>You can unsubscribe from gptalk by sending email to
>>gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
>>field OR by
>>logging into the freelists.org Web interface. Archives for the
>>list are
>>available at //www.freelists.org/archives/gptalk/
>>************************
>>
>>***********************
>>You can unsubscribe from gptalk by sending email to
>>gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
>>field OR by logging into the freelists.org Web interface.
>>Archives for the list are available at
>>//www.freelists.org/archives/gptalk/
>>************************
>
>***********************
>You can unsubscribe from gptalk by sending email to
>gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
>field OR by logging into the freelists.org Web interface.
>Archives for the list are available at
>//www.freelists.org/archives/gptalk/
>************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR
by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR
by logging into the freelists.org Web interface. Archives for the list
are available at //www.freelists.org/archives/gptalk/
************************
***********************
You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at //www.freelists.org/archives/gptalk/
************************
Other related posts:
