Why MTA Gateways are Not Effective SaaS Email Security Appliances

Don't change your email security. Change the way it is connected. With the massive adoption of Office 365 and G-Suite for corporate email, companies hoping to implement additional layers of email security are looking at the traditional companies Proofpoint, Mimecast, Cisco IronPort, and others. In the last few years, these companies have changed their appliance-based business model to offer a SaaS-based service. While they are technically 'cloud-based,' they are not 'cloud-native'. They still deliver their security in the old way, via an MTA-based proxy that reroutes all email traffic through their servers. What makes an MTA gateway a poor email security appliance? Is there an alternative? No matter what MTA-based product you use, you just might like it better if you deploy it via API. (Jump to table)

 Why not an MTA email gateway? Why is API Better?

1. Because you need to scan all email traffic: inbound, outbound, and internal.

MTA-based solutions normally scan only the incoming email flow. This is a critical attack vector, but it is not the only one, especially not with SaaS email. Scanning employee-to-employee and employee-to-external emails is especially important for SaaS email security because the corporate accounts are accessible from anywhere, and often attackers are leveraging stolen credentials to launch more attacks. For example, in some some real-world examples, attackers will reply to internal email threads with malicious files, send phishing links to partners and customers, or send malevolent instructions to the company's bank or suppliers. (Here's a report of such recent attack.) When securing organizational email, any solution should adopt the zero-trust model: assume that attacks could originate from anywhere, including internal accounts.

2. Because an MTA gateway is another point of failure

By adding another hop into your Email traffic flow you are adding another point of failure, reducing the service availability of your most critical business application - email. Google and Microsoft have made massive investments into their highly available infrastructure--accessible from anywhere with the lowest latency. You are paying for it and you want to enjoy its benefits. With the API based approach you can add security without another point of failure because it is completely out-of-band. When running, users only see their emails after those are cleared by the security tools. But if the security service happens to fail, the emails flow directly and users are not effected. 

3. Because you don't want to tell the hackers what you are using for security

The MTA based solutions require that you change your DNS MX record to point to the security provider instead of your SaaS email provider. The problematic side effect is that any hacker can know what security service you have selected. They often reverse engineer it in a replicated environment and eventually send you malware that they know can bypass your security measures. The API-based solution does not expose the security you chose. You can add multiple security tools, as many as you choose, all scanning in parallel all emails, all invisible to potential hackers.

4. Because you want it to be easy to evaluate and deploy

To deploy an MTA requires you to change the DNS MX record and make a configuration change in the SaaS. Though it is not overly complicated, you must interrupt your email flow even if you are just evaluating the solution–all incoming email must be redirected. With an API-based solution, all you do is approve the app in the SaaS app-store, literally one click. Nothing in your traffic flow is affected. You can monitor and then selectively enforce individual users to test the end-user experience move users gradually. If you ever want to disable it, it is a single click. This is the ideal evaluation experience for every security tool, but it is just not possible with an MTA.

5. Because you want the best experience for your end-users

Recently, one of our customers who had already deployed an MTA-based solution asked us to deploy the very same product, but on our API-platform. There was no difference in protection (we run the very same code on our platform as runs in the MTA product). Why? The end-user experience. First, administrators are given more enforcement options vs just  'allow' and 'block'. Through the API, we can offer the user options to 'trust this user' or 'release from quarantine' or offer to sanitize a suspect file rather than just delete it. Second, for files that might take longer than usual to scan, email can be passed through immediately with an informational message or sanitized version of the file. Using the API, the file can later be attached to the message within the user's inbox, eliminating the frustration of MTA-delayed email. Finally, and most importantly, is the ability to scan and retract historical emails. For example,-reputational filters might discover a malicious URL 10 minutes after an email has been passed through. Once an email passes an MTA, it is too late. With an API-based deployment, the solution can change and retract a previous decision. All these provide not just a more secure solution, but a solution that seamlessly integrates with the native SaaS experience, implementing workflows that make it simpler for your company to adopt.

6. Because it's not just email. 

Protecting email is extremely important, but Office 365 and G-Suite are not just email. They are file sharing, collaboration, messaging and more. All of these applications can be used to impersonate corporate users, share malicious files or send phishing links. MTA-based solutions are completely blind to these services. This is even more problematic because both Google and Microsoft also focus their security on email and neglect the rest. For example, Microsoft's Advanced Threat Protection (ATP) can only be applied to incoming email.  

7. Because no single vendor can do everything.

With MTA, each security solution you stack is another hop, which in practical terms means you will only add one. But as we know, no single vendors does everything well. Some have great Anti-Phishing capabilities, some have the most advanced Anti-malware, and another may be your choice of DLP. But you are limited to one MTA so one vendor. The API approach does not have this limitation. Installing new security layers is just like installing apps on your phone, having all of them running in parallel and syncing through a single policy to make a decision on Email flow. This is part of the unique value that Avanan's multi-vendor SaaS security platform provides.

SaaS Email Security - Summary

When the email server was sitting in your data center, an MTA email security appliance was the only option to protect it. Today, SaaS email brings one more advantage: you can secure it through API. Cloud-enabled does not just mean 'in the cloud'. To be truly cloud-native, it must integrate with all your cloud applications using native API. No matter what email security you use, it can offer better security if deployed via API. The following table summarizes the two options for securing your SaaS.

	Security Deployed via MTA Proxy Gateway	Security Deployed via API
Scan all email?	No. Incoming only, not scanning internal and outgoing email.	Yes. All email scanned: incoming, outgoing and internal.
Fail-open?	No. By rerouting all traffic through an MTA you introduce another point of failure.	Yes, while the app is running all email is cleared before the user can access it. If the app fails, emails passes through to inbox.
Security exposed to hackers?	Exposed. By changing your DNS MX Record you are telling the hackers what security you are using.	Your security is protected. All the hackers see is your Email provider at the front, your security runs is hidden in the background.
Ease of deployment	Medium complexity. Configuration required in SaaS email and DNS. No 'view only' mode without traffic redirection.	Easy, just approve the app within the SaaS app store, and the added security layers start taking effect.
Easy end-user workflow	Limited. Once the scan completes an email is either blocked or passed to end-user.	Native-experience workflows: asking if a user trusts the sender, informing of delay, retracting previous verdict, etc.
Extend beyond email	Limited to email	Extends to all of Office 365 including OneDrive, Sharepoint, Skype, the complete G-Suite, and other SaaS applications.
Multi-vendor/ multi-layer security	No. You need to select one vendor to provide all security layers	Yes. Multiple layers from different security vendors can scan your email flow in parallel and make a single policy decision.

Want to scan your Email for malware or phishing? Avanan is here to help. Sign up for a free demo or 14-day free trial and see how our anti-phishing and anti-malware software can protect your accounts.