Hi Thomas,
Nice observation!!
I just finished a call with TAC and they explain the same to me.
Here is the explanation:
">> AV over MTA works based on confidence and this URL has a very low confidence therefore we do not block it in AV or MTA. This new design is made to prevent FP incidents.
>>AV over HTTP does not have the same capabilities yet and therefore browsing to this link was blocked"
However, in my opinion, there is a flaw in the design here which can still be used by attackers or lead to massive confusion for security administrators.
Let's say I am sending a malicious low-risk link to the user. the flow here is :
Email scanned by MTA --> the link found as benign due to low-risk level (less than 60) --> email passed on to the user --> user clicks on the link inside the email --> link is stopped by URL filtering/AV reputation or by the endpoint AV /SBA (or not)
so what happens is that the email will pass the MTA but the link will be stopped in the network layer (or worse if the user is outside of the network perimeter and not protected by the gateway it will allow access to the malicious website and then we are in the hands of the endpoint AV/SB agent)
So we have 3 scenarios which lead to bad user experience in case of:
1. False Negative by MTA / False Positive by the Network AV/URLF
the email arrived to the user and he clicked on the link which was blocked by the network AV/URLF
link shouldn't be blocked because it is a false positive
2. True Negative by MTA / True positive by the Network AV/URLF
the email arrived to the user and he clicked on the malicious link which was blocked by the network AV/URLF
the user shouldn't get the email on the first place because it is malicious (the MTA doesn't do its job)
3. True negative by MTA / user is outside of the network perimeter
The email arrived to the user, he clicked on the link and the malicious content is downloaded to the PC. let's hope that the Endpoint AV/SBA/forensics can identify it as malicious
The inconsistency between the same engines verdict on different attack vectors is problematic for security administrators. the whole issue started because I didn't understand why a malicious link was not stopped by one vector (email) but was stopped by another vector (web link). there is also no way to understand or compare the difference between the different engines. this is why I opened the TAC case which took more than 2 months to figure out by the support engineers.
I can send an email with malicious links which will not be blocked by the MTA and might or might not be stopped by the gateway/endpoint
inconsistency = inability to know if the link is malicious or not.
I understand that the goal is to lower the false positive rate, but I would also would like to prevent my users to get links which are already been scanned by the MTA and can be malicious. In my opinion, allowing users to click on links that might be malicious is defying real-time prevention since it can be too late. It should be stopped by MTA