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

Auto comply with policies

Hi,

I been using the Sophos Data Protection Suite for approximately 5 years, and presently on console 5.2.1 and endpoint 10.3

I've requested as a development enhancement through tech support several times which seems to go into a black hole.

Basically we apply tamper protection to prevent staff from disabling/altering any of the products settings.  However IT staff do need to turn off the firewall, etc to do various tests.  The problem is that they forget to turn the protection back on, and comply with the policies.

What I want on the endpoint is a pop up box when removing tamper protection, and subsequently disabling features (in otherwords, not compling with the policies).  The pop up should ask the user how long before it re-complies with policies, such as a dropdown offering 1 hour, 4 hours, upon next reboot).  A bit look the snooze option for windows updates.

This has been around in other vendor products for years, and I'm gobsacked Sophos are missing this trick!  It also leaves open a big security risk.

Does anyone know if this is on the roadmap? Or can you point me to a Sophos employee who can escalate my request, rather than putting it in the bin.  First line support seem to read off a script and not action my requests.

I look forward to anyone's response.

Thanks,

Jon

:51528


This thread was automatically locked due to age.
Parents
  • Hello Jon,

    what SOP means

    Standard Operating Procedure :smileyhappy:

    [not] overally complex

    :smileytongue: I probably don't want to know what something could be you'd call complex :smileywink:. Seriously, the devil's in the details (the Message Router - or the another service - could be stopped, which process should run the timer, and so on). I don't say it can't be implemented but it won't be perfect. One example that just crossed my mind: One or more reboots might be required for troubleshooting - which timeframe should be chosen?

    Cloud product [vs.] SEC

    Don't think the on premise solution is being neglected. The products target different albeit partially overlapping audiences. The current implementation of the policy reset might not go down too well (as either being insufficient or dispensable) with many existing SEC customers.

    any unnecessary risk

    As said, a device should be returned to normal operation and tested before it's "given back" to the user. I can see that "turning back on AV and firewall" might be the only special actions and autocomply would be convenient. But then - how often do you forget to lock up your office when leaving? Knowing that it will be locked automatically after some time, wouldn't you adopt to constantly "forget" locking up? As the timeframe for autocomply is more or less arbitrary wouldn't that lead to more exposure than an exceptional "forget" (which admittedly will happen - I remember a case where back then - the computers were heavy mainframes, the operators priests, and the system programmers demigods - someone forgot to reset the debug switch on the console panel and the system suddenly came to a complete halt at a very inappropriate moment ... )?

    We all want a product that's top-notch, reliable, fully-featured, highly configurable, simple to use, easily expandable, and all but free. So far I know of such which satisfy all these requirements except 5 and 7 ... :smileywink:    

    Enough of this blabber. Don't expect autocomply any time soon (but, hey, I'm not good at fortune-telling and it might come all of a sudden), Jak's suggestion is definitely worth considering.

    Christian 

    :51768
Reply
  • Hello Jon,

    what SOP means

    Standard Operating Procedure :smileyhappy:

    [not] overally complex

    :smileytongue: I probably don't want to know what something could be you'd call complex :smileywink:. Seriously, the devil's in the details (the Message Router - or the another service - could be stopped, which process should run the timer, and so on). I don't say it can't be implemented but it won't be perfect. One example that just crossed my mind: One or more reboots might be required for troubleshooting - which timeframe should be chosen?

    Cloud product [vs.] SEC

    Don't think the on premise solution is being neglected. The products target different albeit partially overlapping audiences. The current implementation of the policy reset might not go down too well (as either being insufficient or dispensable) with many existing SEC customers.

    any unnecessary risk

    As said, a device should be returned to normal operation and tested before it's "given back" to the user. I can see that "turning back on AV and firewall" might be the only special actions and autocomply would be convenient. But then - how often do you forget to lock up your office when leaving? Knowing that it will be locked automatically after some time, wouldn't you adopt to constantly "forget" locking up? As the timeframe for autocomply is more or less arbitrary wouldn't that lead to more exposure than an exceptional "forget" (which admittedly will happen - I remember a case where back then - the computers were heavy mainframes, the operators priests, and the system programmers demigods - someone forgot to reset the debug switch on the console panel and the system suddenly came to a complete halt at a very inappropriate moment ... )?

    We all want a product that's top-notch, reliable, fully-featured, highly configurable, simple to use, easily expandable, and all but free. So far I know of such which satisfy all these requirements except 5 and 7 ... :smileywink:    

    Enough of this blabber. Don't expect autocomply any time soon (but, hey, I'm not good at fortune-telling and it might come all of a sudden), Jak's suggestion is definitely worth considering.

    Christian 

    :51768
Children
No Data