Los tenant de Microsoft normalmente son un desorden de cuentas, de administradores, invitados, etc, por lo cual es necesario filtrar a los usuarios sincronizados del tenant de Microsoft por dominio, de manera que todas las cuentas de invitados y con dominio @nombretenant.onmicrosoft.com no sean sincronizadas.

Es fácil excluir a los invitados, ya que existe una opción que permite filtrar los usuarios por type=user, sin embargo no existe la forma de filtrar las cuentas por dominio, la documentación no cubre esta parte de la configuración y la opción de usar filtros LDAP solo aplica para el Sophos AD Sync on premises no la versión para Azure.

Reports that also displays the Sophos agent's version instead of individually clicking on the devices to see what version they are on. This helps with bulk automated uninstalls because the latest version 2.15.4 does not uninstall by disabling SAVService and editing the registry in Safemode when tamper password cannot be recovered. Also when creating the uninstall batch file and querying the registry for the strings, the report that has the agent versions will help with knowing what agent versions are so you do not need to click through all the Windows PCs to see if there's a different version to run the reg query to retrieve the strings to create an uninstall batch file.

I want a High level alert when a server stops checking into Sophos Central. Not just when it goes Inactive (2+ weeks) but any time it stops calling home for 24 hours. I work for an MSP and there is no way I'm going to check on that many client portals in one day just to look for issues; that's what alerts are for. The lack of this visibility has caused us a major liability with a client.

If a connection check isn't possible, then have Device Not Updated alerts happen implicitly when a server doesn't call home for 24 hours. Virus definition updates happen every few hours; a server will be out of date if it isn't checking in at all.

Automatic replies from an Out of Office assistant or from an configured rule to any "noreply" emails should can be blocked.

There should be a possibility in the Email Gateway Settings or Policies to configure variables of possible Emails like "no-reply", "noreply", "do-not-reply", etc. that if the recipient replies to such an email, this automatically gets blocked on the "outgoing" path.

For auditing, this block should be listed in the "Logs & Reports - Message" List, that the admin sees "From User XY an Email to "noreply@XYZ.TLD" got blocked and deleted.

The sender should not get any information that this happen because if the reply was done by the OoO assistant or a rule, this would "spam" the mailbox of the user.

Ill put this feature against Email Gateway as that is where is sorely needed but this feature should be for all Sophos Central components.

Part of the power of Sophos Central should be centrally across all security product reacting to a security event and taking action to resolve it.

Currently there is no "Block URL" feature in Email Gateway - There is an URL Allow list but no block feature. This is sorely needed.
One of the main benefits of using Time of Click is to immediately react to issues not only on future emails but existing emails in users mailboxes. Yet there is a reliance on Sophos Labs to have information on Malicious URLs which often they do not...

If a URL is indicated in a phishing email that slipped through, a company admin, using a URL Blocklist, can IMMEDIATELY react to this and block the URL for all existing emails that have that URL and emails received in the future. The company is immediately protected from a Email persepective.

Sophos can use this list as a sample submission of sorts also to validate and potentially block that URL for all Sophos customers.

--

Additionally there should be a means of blocking IOCs - Domains, URLs, IPs, Hashs - across all products in Sophos Central. -- Global Block List

URL on the Company Global Blocklist would mean --

• Block URL in Web Control for Endpoints and Servers and Mobile (this is possible using the web tag system BUT ridiculously convoluted)


• Block URL in connected XG Firewall


• Block URL at the device level for Sophos Wireless users.


• Block URL in Email Gateway for ToC emails also


• Quarantine email that is specified in the new Search and Destroy feature.

That is ridiculously powerful and massive missing potential from Sophos Central.

I just learned through a support case (where a spoofed malicious email was allowed through, bypassing DMARC checks despite having an inbound DMARC verification rule) that the only time an inbound DMARC verification rule is even TRIGGERED is when DMARC actually "fails" (because the domain's various records for SPF and DKIM don't have the proper servers allowed)..

Unfortunately, I also learned that, when the sending domain does not actually HAVE a DMARC record to check, such a "failure" is technically not possible... because 'DMARC record does not exist' DOES NOT EQUAL a "fail", and there is no "does not exist" scenario that is currently allowed for regardless of the action ("honour txt record", "quarantine", or "reject") chosen for the rule.

What this means is that a spammer has the ability to send all the spoofed email they want from (and potentially to!) your OWN domain without your inbound DMARC rule doing anything to stop it.

This is NOT due to a misconfiguration of YOUR OWN records for DMARC. It is a failure of the sending domain's LACK of a DMARC (or SPF/DKIM records, as appropriate). (Furthermore, and similarly, though, I was also educated by Support that the SAME THING would be true if the SPF record didn't exist, or if there were NO DKIM records either (the message would just skip DMARC checks and be allowed through).

Currently we are technically using the email appliances - however, my understanding is that this is how the feature works in Sophos Central as well, so, I'm submitting this now in hopes it will be fixed, in advance of our possible transition to that service from the appliances.

The solution I'm suggesting is to have an option to treat a "non exist" as a "failure" so that DMARC verification can actually be triggered. Maybe there can just be options to override the handling of when the DMARC, SPF, or DKIM records do not exist... we could just pick 'quarantine'?