Customers that use gateways like Mimecast, Proofpoint, Barracuda and IronPort might be susceptible to email attacks that other Office 365 and Gmail customers are not.
Mimecast and Proofpoint were the premier email security solutions for legacy on-premises email platforms, such as Exchange or Lotus Notes. But using them for cloud-based Office 365 or Gmail actually blinds Microsoft and Google's default security. In some cases, you are better off without these email gateways.
Mimecast and Proofpoint Blind Built-In Security for Office 365
Introducing an MTA (a Mail Transfer Agent that changes your MX record) will blind Microsoft and Google's default security to incoming threats.
As a security company, we observe many phishing attacks. Among these, one of the most persistent threats is also the most ironic: deploying a secure email gateway from Mimecast or Proofpoint allows emails that would have been blocked by Office 365 or Gmail to bypass all security.
This boils down to spending money on a security solution that actually worsens your security posture.
When you double-stack your security with a secure email gateway, you must disable Microsoft and Google's spam filters — which play a key role in anti-phishing. This is why upon deployment, you will often be advised by Proofpoint or Mimecast to disable your default spam filtering and rely solely on the gateway.
Installing a secure gateway makes emails bypass the native security of your cloud-based email provider.
Email security solutions like Mimecast and Proofpoint change certain indicators in the email's header, blinding some critical aspects of the default security layers in Office 365 and Gmail.
This would not be a problem if the SEG caught 100% of attacks, but this is not always the case, especially in the first hours or days of an event. From a ‘defense-in-depth’ perspective, it is disheartening to know that in order to deploy a second layer of security, you must essentially disable the first.
Why Do Proofpoint and Mimecast Interfere with Microsoft?
After the email passes through the gateway, Google and Office 365 can no longer interpret two main indicators of phishing because:
1. The sender's IP address is changed
After Mimecast or Proofpoint is configured, O365 and Gmail no longer see the IP address, which identifies the original sending server of the email. As an email passes through the secure email gateway, it replaces the sender’s IP with its own IP address.
The following information also becomes unavailable, making the related security dysfunctional:
- sender scoring
- Block Listing of senders
- ISP information and its reputation
- geographic information
When all mail going through the gateway is “from” the gateway, identifying threats becomes more difficult.
2. Sender Policy Framework (SPF) fails
Email providers prevent sender address forgery using SPF, a DNS-based security protocol/mechanism, by verifying the sender’s IP address against the sender’s domain.
With this in mind, imagine you’ve deployed a secure email gateway atop the default security stack of your cloud email. In the same day, the cloud email server receives a legitimate and spoofed email from Bank of America. For both emails, SPF has failed because your email provider sees the secure email gateway’s IP is not allowed to send on behalf of the sender’s domain.
Because of this issue, Proofpoint and Mimecast tell you to disable the spam and phishing filtering of your email service. Although SPF is not fail-proof, it remains an important indicator of the genuineness of the email.
How Hackers Take Advantage of Gateways
One of the most basic email checks is the SPF and DKIM authentication of the sending SMTP server. This validates that an email from "company.com" truly came from "company.com". However, when you change your MX record and send it through a gateway, every email is sent from the MTA IP address (as we discussed above) and fails both of these fundamental checks.
So, in order to prevent Microsoft from rejecting every email sent by the MTA gateway, you must put the Mimecast and Proofpoint servers on a list of "Trusted Servers".
"To ensure emails are delivered from Mimecast to Office 365, the Mimecast service IP Ranges should be added to the Allowed List in the Connection Filtering Policy within the Office 365 Exchange Admin Center (EAC).” - Mimecast Deployment Instructions
Unfortunately, this "Allowed List" transport rule effectively bypasses Microsoft's own protection.
You can see this in the header of every email that uses an MTA (see Microsoft Message Headers).
So, from Office 365's perspective, this IP address that belongs to Mimecast is marked as a trusted sender for every email. Therefore, every email will bypass Microsoft's filters and be delivered to the user's inbox. If the MTA misses a malicious email, Microsoft's own security will never see it.
Why Securing Email from inside The Cloud Is Important
Avanan is uniquely positioned to measure the effectiveness of Microsoft's email security. Because we connect via API, we are able to scan email in the line of email traffic — after it has been scanned by Microsoft, but before it arrives in the inbox.
This is true across all of our customers — regardless of if they use only Microsoft's default security, Advance Threat Protection (ATP), or Mimecast and Proofpoint. This allows us to compare the effectiveness of each email provider's security during large phishing or malware outbreaks.
Avanan’s anti-phishing solution is different than Proofpoint and Mimecast in a few key ways:
1. It Enables One-Click Deployment
Because Avanan is deployed internally, we are uniquely positioned inside of cloud email. We scan internal threats with no additional, cumbersome configuration, as is the case with gateways.
- Approve our app from your admin account and in minutes, Avanan connects directly to the native API of your Office 365 or Gmail environment—completely out of band, with no need for a proxy, appliance, or endpoint agent.
- We see everything that Google and Microsoft can, and catch threats that were specifically engineered to bypass them.
Rather than replacing one security layer with another (as you would have to with Proofpoint or Mimecast), Avanan is another security layer added to the default security in the platform. Working via API, we scan emails after they pass through Microsoft's filters, but before they reach the inbox — focusing specifically on what they miss. Because we connect directly to Microsoft's back end, we can analyze and block a malicious email before it gets to the user's inbox.
Deploying via API gives Avanan 100% visibility and more advanced enforcement. Because we are working within Microsoft's infrastructure, we can monitor inbound, outbound, and internal email that would normally be missed by an external email gateway. In fact, we can go back in time and search the company's inbox for past attacks, identifying compromised accounts.
More importantly, we can reach into a user's inbox and quarantine emails that are discovered to be malicious after they are delivered. (For example, when it was discovered that an internal account had been compromised, we were able to quarantine every previous email sent by that account across the enterprise.)
Hackers Can't See What Security You're Using
Secure email gateways require that you change your DNS MX record to point to the security provider instead of your cloud email provider. The consequence of this setup is that any hacker can know what security service you have selected and reverse engineer it in a replicated environment to eventually send you malware that they know can bypass your security measures.
On the other hand, API-based solutions do not expose the security you chose.
