Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 6911 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Preventing Sophos services from being disabled by domain users

Dann-PLC

Hi All,

Good to see there is finally a forum to post idea and questions out to end users!

I have a question that I hope someone can answer...

Im looking at rolling out EndPoint 9 to the company and we are going to start using the Sophos Firewall etc.

I wanted to know if there was a way to stop end users disabling or stopping sophos windows services to prevent them from navigating around the device control/firewall etc... 

I realise this is a Windows question more than Sophos and have looked at GPO secuirty settings but cannot get these to work with DENY permissions. It also seems that when I configure any rules in these services in GPO, Sophos AntiVirus service doesnt start up.

Just wondered if there was a way of doing this in Sophos based on the sub estate/roles or anything else...

Thanks!

Dann

:120


This thread was automatically locked due to age.
Parents
  • 0

    We managed to wrestle the power users rights from both domain users and non-domain "VIP" notebook users (that we were hit by an outbreak of Conficker did help a lot).

    From what you say I gather that you don't have the required backing from your management to enact the policies you deem necessary - and you are trying to "sneak in" a little bit more control. I recommend against it. Such course of action could backfire any moment. You have a job to do and for that you need certain resources - and these include the approval of necessary policies (and the "right" to enforce them).

    If you can convince the users that your actions are for their benefit - fine (management always likes to make decisions which meet no resistance). If not, then you have to convince management - for this you need a "business case" (number of "incidents" on IT-managed vs. partially-user-managed computers for example). If certain applications only (seem to) work for power users try to identify the cause. Show that you care about the users' needs and that you are willing to find workarounds and implement exemptions - while clearly stating the consequences (reduced security, additional effort) and the responsible party (most of the time it's either a sloppy implementation by the vendor or simply "unfit" software and not exactly your fault). This worked for "us" (i.e. the group in IT responsible for the endpoints) - even though most of our colleagues called it mission impossible.

    The bottom line is: When trying to achieve a strategic goal it is better (and easier) to permit specific actions, especially when it's clear that they are exemptions.

    Christian

    :212
Reply
  • 0

    We managed to wrestle the power users rights from both domain users and non-domain "VIP" notebook users (that we were hit by an outbreak of Conficker did help a lot).

    From what you say I gather that you don't have the required backing from your management to enact the policies you deem necessary - and you are trying to "sneak in" a little bit more control. I recommend against it. Such course of action could backfire any moment. You have a job to do and for that you need certain resources - and these include the approval of necessary policies (and the "right" to enforce them).

    If you can convince the users that your actions are for their benefit - fine (management always likes to make decisions which meet no resistance). If not, then you have to convince management - for this you need a "business case" (number of "incidents" on IT-managed vs. partially-user-managed computers for example). If certain applications only (seem to) work for power users try to identify the cause. Show that you care about the users' needs and that you are willing to find workarounds and implement exemptions - while clearly stating the consequences (reduced security, additional effort) and the responsible party (most of the time it's either a sloppy implementation by the vendor or simply "unfit" software and not exactly your fault). This worked for "us" (i.e. the group in IT responsible for the endpoints) - even though most of our colleagues called it mission impossible.

    The bottom line is: When trying to achieve a strategic goal it is better (and easier) to permit specific actions, especially when it's clear that they are exemptions.

    Christian

    :212
Children
No Data