The majority of companies still use legacy gateways to protect their email.
More and more, however, companies, are realizing the limitations of this approach, was originally built for the on-prem era.
The API approach is gaining steam, and Avanan has led the revolution, as it founded this method. In this blog, we'll talk about the key reasons as to why the API deployment is preferred.
1. Because you need to scan all email traffic: inbound, outbound, and internal.
SEGs 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 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 a 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. If a SEG goes down, you're stuck.
3. Because you don't want to tell the hackers what you are using for security
The SEG 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.
4. Because you want it to be easy to evaluate and deploy
Deploying a SEG 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 a SEG.
5. Because you want the best experience for your end-users
API-based security offers more options and functionality. Take 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 a SEG, 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.
Summary
When the email server was sitting in your data center, an SEG 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
Secure Email 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 a SEG 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 |
|
