It seems an old problems reoccurs - we see "false positive" spam confirmed blocked E-Mails from MS 365 senders at our customers...
We see "spam confirmed" for some MS 365 Mailserver IPs:
40.107.4.116 or 40.107.22.101 or 40.107.3.125
If I check that with cyren - it is green / no risk - also when I check different blacklists for this IPs
Maybe corrupt pattern?
Seems this problem is back:
Anybody else can confirm this?
These types of problems will happen, and a good email filter should provide you with a way to solve them. In the case of Office365, the required filter rule would be:
If ReverseDNS name ends with ".outlook.com"
AND the ReverseDNS name can be forward confirmed to the IP address
THEN bypass spam-filtering
But you cannot create this type of rule in UTM (or many other products).
The point here is that you need two pieces of information for ANY type of whitelisting rule: one or more expected identifiers AND evidence that at least one of the identifiers is verifiable and therefore has not been spoofed. Verification can be based on Source IP, host name, SPF, or DMARC. Examples:
What is consistent for all of these scenarios is that a safe whitelist rule requires at least one verified identifier.
In this particular case, you cannot know all of the Office365 servers, so you need to validate based on host name rather than IP address. Usually, HELO name is preferred for server verification, because it should reflect the server organization while the ReverseDNS name might indicate the ISP organization. Office365 is an exception. Both HELO and ReverseDNS names use the same domain name, but ReverseDNS is the only name that consistently verifies using forward DNS lookups.
Obviously, Office365 includes a lot of organizations In this situation, you may prefer to lose some messages for awhile, rather than accepting the exposure created by a bypass rule. But the choice should be yours. You should not be constrained by the limitations of an email filter than cannot do two-attribute whitelisting.
There are a lot of products that do not allow two-attribute whitelist rules, so shop carefully when you start looking for your next email filtering product. It seems obvious that UTM is not going to change much, and sooner or later we will all be looking for replacement technology. For email, Sophos hopes that we will choose Sophos EMail (in the Cloud). I don't have a firm answer on whether it provides safe whitelisting based on this approach, but I will not buy a product that cannot do so.
These types of problems will happen, and a good email filter should provide you with a way to solve them. In the case of Office365, the required filter rule would be:
If ReverseDNS name ends with ".outlook.com"
AND the ReverseDNS name can be forward confirmed to the IP address
THEN bypass spam-filtering
But you cannot create this type of rule in UTM (or many other products).
The point here is that you need two pieces of information for ANY type of whitelisting rule: one or more expected identifiers AND evidence that at least one of the identifiers is verifiable and therefore has not been spoofed. Verification can be based on Source IP, host name, SPF, or DMARC. Examples:
What is consistent for all of these scenarios is that a safe whitelist rule requires at least one verified identifier.
In this particular case, you cannot know all of the Office365 servers, so you need to validate based on host name rather than IP address. Usually, HELO name is preferred for server verification, because it should reflect the server organization while the ReverseDNS name might indicate the ISP organization. Office365 is an exception. Both HELO and ReverseDNS names use the same domain name, but ReverseDNS is the only name that consistently verifies using forward DNS lookups.
Obviously, Office365 includes a lot of organizations In this situation, you may prefer to lose some messages for awhile, rather than accepting the exposure created by a bypass rule. But the choice should be yours. You should not be constrained by the limitations of an email filter than cannot do two-attribute whitelisting.
There are a lot of products that do not allow two-attribute whitelist rules, so shop carefully when you start looking for your next email filtering product. It seems obvious that UTM is not going to change much, and sooner or later we will all be looking for replacement technology. For email, Sophos hopes that we will choose Sophos EMail (in the Cloud). I don't have a firm answer on whether it provides safe whitelisting based on this approach, but I will not buy a product that cannot do so.
Interesting enough that Central Email does this already with the power of SophosLabs.
So we are doing this and much more in the Central based approach. Because there is one additional part of Check, you can do: Its the message itself and the content of the message.
Sophos Labs with the power of machine learning is focusing in such matter a lot because it is quite simple to create a spoofing Email address within outlook and simply spoof people all around the world. And as such, those emails are always "valid" to your checks. If you would start to rely on such checks alone, it could be easily avoidable by using Microsofts own infrastructure to spoof customers. Phishing nowadays has advanced in more detailed ways.
Central Email uses FROM and envelope-FROM checks already to block and protect the spoofing and enhance this with the classic protection like SPF, DMARC etc. Also terms like Delay Queue are already included plus the known hosts. Central provides a single MX, we can use the information of all customers to enhance the methods of blocking / allowing the email solution. The best part: This is done by SophosLabs and not the customer. As a customer, i do not want to get into this allow/blocking part and think about this kind of stuff. It should simply block the bad stuff and allow the good stuff - right?
Sophos Labs does some magic to fight against the next generation spoofing and phishing. See: https://ai.sophos.com/projects/phishing-detection/
You can see this in a short demo on the same website: https://ai.sophos.com/demos/sophos-ai-catbert-phishing-detection-model-demo/
Also there is a long defcon presentation about this: https://ai.sophos.com/presentations/def-con-28-ai-village-detecting-hand-crafted-social-engineering-emails-with-a-bleeding-edge-neural-language-model/
__________________________________________________________________________________________________________________
This is good. I have no small frustration that Sophos has offered so many email filtering products but has been so slow to figure this out. (2 PureMessage embedded products, 3 appliance products, and 1 discarded cloud product before this solution.) But better late than never.
Feature Question:
Another feature question: Does Central Email have the ability to scan the entire Received chain to check for threat actors hidden behiind a forwarding operation? Example: John@alumni.example.edu is an auto-forwarding service provided by John's college. Everthing gets forwarded to john@mydomain.com
John gets both legitimate mail and malicious attacks sent to the alumni address. When it arrives at mydomain.com, the forwarding process replaces the originator reputation with the university's reputation. To block the malicious content based on source identity, we need to scan the entire received chain, and block any IP address or host name that is on a configured blacklist.
This is also relevant for DMARC. Mailing lists alter a message while forwarding it, to add list-specific identification. How well can the neural network determine that a message has been through a mailing list, and what are my options to allow trusted mailing list traffic to ignore DMARC failures?
I am actually troubled by this comment: "The best part: This is done by SophosLabs and not the customer."
Can you clarify how roles are split between SophosLabs and the system manager (me?)
I make a distinction between "malicious" messages and "unwanted" messages. All of your clients want malicious messages blocked, and you have the best information in most cases. But how far am I required to trust you? When I experience a particular attack pattern, I want to ensure that I can block it immediately, rather than submitting a sample and hoping that it becomes a global block rule before disaster happend to me. Will Central give me the tools to do this?
Just as significantly, the distinction between "wanted' and "unwanted" is specific to each organization and user. We have found that we can block a lot of unwanted advertising by blocking the string "UTF-8" in the subject line. But we also have a lot of exceptions to that rule so that business-relevant advertising will get through. With the right filtering tool, anyone could use this approach, but the exception list will be different for different businesses. Will Central allow me to control my mailstream down to the "wanted" level, or am I limited to blocking traffic that is unwanted by everybody?
