Does Traditional Third-Party Message Security Make Sense in an M365 Environment?

M365 and Email Security

In my last post, I discussed the risks of storing your data in a legacy archive repository that is end-of-life, broken, or somehow inaccessible. I’d just finished retrieving data stored in an unsupported platform for a client faced with a time-sensitive ediscovery request. When something like this occurs – and believe it or not, it happens more often than you think – it’s like your data is on fire. In other words, you have an emergency, getting to the data is super time sensitive, but you cannot get to it. Not ideal, to say the least…

Without wanting to sound overly dramatic, another project I just completed made me think about something else – you might be setting your money on fire if your migration to the cloud was frivolously old school.

What do I mean by that? Say, you opted for M365, you got your E3/E5 subscription with all the cloud security and compliance tools included, but you still decided to continue to use the third-party messaging security product that was part of your in-house infrastructure. This could be an on-premise security appliance or more likely a third-party cloud provider.

The question is, does it make sense to pay extra for licenses and use these services if you have moved your email to a cloud platform such as M365? Furthermore, is this third-party service configured correctly to protect your messaging system from spam and other phishing attacks?

The main problem with products designed for protecting on-premises email systems is that they still utilize an archaic design methodology. Therefore, they aren’t equipped to deal with the new model of having email reside behind a cloud-native firewall.

Protecting Your Email in the Cloud

Here’s what I mean. The way third-party email security products traditionally work is pretty straigh-forward. First, you need to point your MX record to them. After that, you configure your firewall to accept data traffic only from their IP address. Simple, right? Not exactly, when we are dealing with the cloud…

When you migrate to the Microsoft cloud and create your company’s tenant in M365, in addition to your company’s MX record (e.g., mail.yourcompany.com), a second MX record gets created that you have no control over. Typically, it would be the tenant name plus “mail.onmicrosoft.com”, i.e. “yourcompany.mail.onmicrosoft.com”. This is your “other” MX record. Microsoft controls this, not you.

And that’s where the problems begin for many clients. Even though, you have pointed your MX record to your third-party security provider, you are still at risk. Your “onmicrosoft” MX record is easy to guess, and once a malicious entity gets hold of it, they can send email directly to that address, completely bypassing your third-party security provider. This vulnerability is known as a Root Domain Hack.

In 2020 an estimated 70% of all successful phishing attacks at M365 were due to “Root Domain Hacks” when using MX redirection. New research shows over 30% of phishing emails sent to organizations using M365 reached users’ inboxes. Of those, 50% contained malware, 41% were aiming credential harvesting, and spear phishing and extortion make up the remaining 9%. The reason these fraudulent or spam emails pass through the corporate messaging environment is incorrect security at the cloud perimeter.

You Can Improve Messaging Security and Simplify Management

A case in point is the recent project I worked on. My client, a large healthcare provider in Arizona, had moved to M365 a couple of years ago. Even though the Microsoft offerings were part of their subscription, they hadn’t configured the necessary policies and had continued to use their old email security service. When the time for license renewal approached, they approached me for advice. They were looking for ways to reduce their IT spend and, in the process, streamline their IT operations.

I am happy to share with you my client was very pleased with what we accomplished:

• We simplified their messaging infrastructure by removing the old third-party email security service. Result: Annual cost savings of more than $10,000.00
• We configured MS EOP/ATP for email protection and MS Purview for DLP (Data Loss Prevention). Result: Reduced complexity of email management and increased control over their messaging environment.
• By deploying Microsoft security, we extended the perimeter of protection beyond email, to Teams, SharePoint, and the files residing on OneDrive. Result: Optimized the M365 investment, something their current messaging security provider could not do.

In conclusion, I would like to highlight once again that it’s really worth looking into your M365 subscription and all it has to offer. For years, Microsoft has been expanding and strengthening its security suite, and this has been validated by analysts who have consistently recognized its position as a leader in the space. Right now, Gartner has them in the top quadrant on the tail of Proof Point. If you are already on M365, you can cut costs and reduce the complexity of managing your cloud environment. If you need some pointers where to start, give me a call / drop me a line. I know I can help.

About Chuck

Charles Arconi is a Principal Architect at iShift who has 25+ years of IT experience architecting and deploying cloud-based email and communication technologies. For the last 10 years, Chuck’s primary focus has been migrations: data to the cloud, email to Office 365, archiving data to cloud, etc. He is an accomplished technologist who likes direct interactions with clients, speaking, explaining, and strategizing about technology with them.

He also is a think-out-of-the-box kind of guy who likes to challenge mainstream practices and design innovative methodologies for the sake of efficiency, effectiveness, and usefulness. Every month Chuck will offer his take on cloud industry news, cloud-native technologies, and practices, and share his original insights about best practices in cloud computing. You can follow Chuck on LinkedIn or contact him directly at [email protected].

Share this article on: