Allow localized exclusions per machine/client to play nice with global policies from the management portal.
Currently it appears that policy based exclusions prevent the ability to add additional exclusions at an agent or client level.
It would be ideal to have the policy enforced when pushed out but still allow subordinate exclusions to be configured for end user networks and devices.

For example:
I have global policies that apply well to all clients but not all and as a result certain several clients have had to be purposefully removed from the policy target group. Having to reconfigure common exclusions for every client instance is a major time-sink that I feel could be avoided.

Our PCI-DSS Level 1 audit has asked us to show logs when any attempt to kill any Sophos process is done. None can be found, despite Sophos Support claiming an event is logged in Event Viewer - no Event Source, Event ID or other information was provided to prove this is the case. An "Access Denied" Error is generated by tamper protection, that's nice. We have no proof that someone or something attempted to circumvent Sophos until it has actually be circumvented - alert in Sophos central that the computer is no longer protected, nor how long this attempt to circumvent has been underway. Like closing the barn doors after the cows have left.

Use Case:
- a malicious attacker (External actor or disgruntled employee) manages to gain access to a workstation or server via a legitimate path - Powershell WRM or Interactive console access - without triggering any other malicious payload alert by Sophos - an otherwise legit login to the targeted machine/environment (credentials obtained via phishing attack). Then the attacker attempts to stop Sophos. At the absolute minimum an audit log in the Windows Security Event Viewer log should be logged of the attempt, like any other access denied log windows generates for system events. This will allow administrators to see any potential attacks under way that have not otherwise triggered a malicious payload alert or even something in the Tamper Protection logs themselves and not just "Tamper Protection has been disabled". The logs can also be analyzed in real time by 3rd party monitoring platforms like SumoLogic that can correlate the data from the Windows Event Logs, that Sophos is simply not designed to do. And with appropriate setup, can be alerted with Real Time Alerts from the 3rd party monitoring platform or even Sophos Central if the attempt to kill any Sophos process is relayed back to Sophos Central alerting.

Example Log:

An attempt was made to access an object.

Subject:
Security ID: ad\UserName (or Local System Account if accessed via System account)
Account Name: UserName
Account Domain: ad
Logon ID: 0xFFFFFFFF

Object:
Object Server: Security
Object Type: File
Object Name: C:\Program Files (x86)\Sophos\Sophos Anti-Virus\SavService.exe
Handle ID: 0x0000
Resource Attributes: S:AI

Process Information:
Process ID: 0x000
Process Name: C:\Program Files (x86)\Sophos\Sophos Anti-Virus\SavService.exe

Access Request Information:
Accesses: EndTask
Outcome: Access Denied

Currently in Sophos Central we can add servers to a Test Group and prevent all other servers from having their agent update.
This is completely inadequate. Need to be able to create more Server Groups and be able to update to the new version by server group.

Should be able to download a manual install for the new version and apply it to the servers while Controlled Updates is turned on.

This would allow us to update critical servers at a time of our choosing.

Right now, the option is Update All Servers - This is equivalent to pushing the Nuclear Button, especially if the update requires a reboot.

I tried to rerun the SophosSetup and the SophosInstall with a new update available on my Portal. No luck. Server stayed stuck at the previous version!

While working with Support we provided the SDU logs for investigation. Sophos Support came back and requested some additional files not captured as part of the SDU tool. Please add an option in the SDU to include these sources.

To obtain these files we needed to disable Tamper Protection, and copy the files ourselves.

From Sophos Support:
To further progress, we will also require you to copy, zip, and upload the following directories to our FTP. The reason we require these folders is because they contain the snapshots of the event in a .tgz format which our SDU tool does not gather by default

Folder required:
C:\ProgramData\Sophos\Sophos System Protection\
C:\ProgramData\Sophos\Endpoint Defense\
C:\ProgramData\Sophos\Sophos Data Recorder\ [If this folder does not exist do not worry about this]

After upgrading to Intercept X with EDR there are situations where a Threat Case is not created. Sophos Support mentioned a Threat Case was not forwarded to Central because a root cause could not be found. Even when a Root Cause cannot be identified consider creating a Threat Case so customers have access to the additional context information. Perhaps set the beacon as the root cause.

"Note: Threat cases are only created for malicious detections; this does not include detections for PUAs, Application Control, Device Control, Web Control. Additionally if Sophos isn't able to automatically confirm a root cause, a Threat Case may not be generated."
https://community.sophos.com/kb/en-us/125120

After upgrading to Intercept X with EDR in situations where are Threat Case is not created revert to the pre-Intercept X behavior of publishing the Detection Event as an Alert.

"Note: Threat cases are only created for malicious detections; this does not include detections for PUAs, Application Control, Device Control, Web Control. Additionally if Sophos isn't able to automatically confirm a root cause, a Threat Case may not be generated."
https://community.sophos.com/kb/en-us/125120

We've gotten a number of malicious Events which haven't created corresponding Threat Cases for hosts assigned to the Intercept X with EDR policy. Sophos Support mentioned a Threat Case was not forwarded to Central was because a root cause could not be found. When this occurs the Event is not displayed on our Central Dashboard nor in the Alerts tab. This reduces the value compared to Sophos Endpoint Protection since Intercept X with EDR should provide additional context, and we now must query via the Event Viewer under Logs and Reports periodically.

Dear Support Team,

I have observed that whenever you open the Sophos Home Premium agent on the Endpoint (client computer), it has a settings tab located on it. I have observed that by clicking this settings tab automatically takes you to the Sophos Home Premium Cloud Management Console, without even asking or prompting for the username or password on the website, which is quite insecure I would say.

That way anyone using the home computer can change the policies and security settings. I want to enforce certain restriction on the Laptops used by the kids. Since the settings tab does not prompt for credentials, they get direct access to modify the policies.

In addition to to prompt for credentials I would request you to even provide MFA for Advanced users., and simply credentials for standard users.

Please take this on priority.

Thanking you.

Regards,

Hi guys, when Invincea was bought by Sophos I was excited about Invincea's sandboxing feature to be included to Sophos Endpoint Protection.
This however doesn't appear to have been planned.
Useful scenarios include:
- Running unknown/suspicious applications in a sandboxed environment.
- Opening email attachments
- Opening downloaded files
- Manual use by security admins (Specify programs to run in sandbox, or temporarily whitelist a blocked program/file forcing it to run in sandbox for investigations.)

That last one is particularly useful, as we've recently had a case where some emails were flagged by Sophos and quarantined. Sophos would block us from opening the emails, which meant we were unable to investigate the emails in order to create a rule to filter them out.
We had to disable Sophos to complete our investigation, which is very non-user friendly.
Having a simple option of allowing to run a quarantined/blocked program or file from sandbox would solve this issue while keeping the system secure.