Mimecast and Proofpoint customers 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. (In "SaaS Email Security: 7 Reasons not to Use an MTA Gateway," we summarize why an email gateway is not the right solution for cloud email.)
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 MTA 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.
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:
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 for the genuineness of the email.
A month ago, we reported on an attack that was bypassing both Microsoft's default security as well as Advanced Threat Protection. Eventually, Microsoft learned to detect this particular threat, and we stopped seeing the malicious messages.
Almost.
We continued to see (and block) these malicious messages on a handful of customers. For nearly a week, our engineers could not understand why only these accounts were affected. Eventually, we discovered what these customers had in common: all of them had an MTA email security product deployed.
Somehow, the malicious mail was getting by the MTA gateway, but also bypassing Microsoft's own security — which we knew should have been able to block it.
Microsoft's built-in security misses this threat because in order to deploy any MTA Email Gateway like Mimecast or Proofpoint, the customer must first disable Office 365's own built-in security.
Why?
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 an MTA 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 by-passes 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 never see it.
Secure email gateways deploy outside of cloud email to scan inbound and (for an extra price) outbound threats. By default, Mimecast and Proofpoint don't scan internal email, but they offer it — just not in real-time.
Recently, they have introduced a separate product for internal email. Secure email gateways rely on a Rube Goldberg-ian system of tools to quarantine malicious email after they've reached the inbox and have been opened by the victim.
As you can see in Proofpoint's infographic below, these systems:
Some of these systems advertise the ability to track down forwarded emails, which only emphasizes the weakness of the mechanism; by the time they discover the threat, it's already been read, clicked, and forwarded.
Essentially, this is a separate process for scanning internal email. No matter how effective their scanning is, this architecture will never catch threats in real-time.
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:
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.
Deploying from within cloud-based email creates an architectural advantage.
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.
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. You can add as many security tools on our platform as you choose—all scanning in parallel all emails, all invisible to potential hackers.
So, to be clear: this is not about Mimecast or Proofpoint missing a particular email. All security tools miss some. What we are demonstrating is that replacing one security (Microsoft) with another (Mimecast or Proofpoint) might fail you in many cases.
The best approach is to work with what Microsoft gives you in the E3 license, and add a third-party vendor who has tighter integration with the Office suite than Proofpoint and Mimecast.
We turned to one of our customers, a CIO at an IT management company of 3,000 employees who would prefer to remain anonymous. He said, “Avanan caught 162 phishing attacks during our 2-week trial, compared to Mimecast and Proofpoint, which caught 101 and 69, respectively. It even had a better false positive rate."