Today, we’re pleased to announce the release of the Microsoft Defender for Office 365 Migration Guide. If you’re thinking of switching your MX record from another filtering service or on-premises Security Email Gateway, then we hope you’ll find this helpful. Our goal with this guide is to help our customers have a better experience when migrating. The typical way we’ve seen migrations run in the past is to attempt to copy as much configuration as possible, then switch the MX record and hope for a good experience. This way might be fine if you have a small domain or a simple configuration with little or no organizational security response. But for the larger, more complex cases, we’ve observed that this way usually makes for a bad experience for users and for IT admins and security teams. Instead, this guide allows you to use a data-driven, waterfall approach that really helps everyone build their confidence that the MX record switch is going to go smoothly before signing off and doing it.
Email security is a balancing act and getting it right isn’t easy
No email security product gets 100% on both detections and false positives. A real-world approach requires balancing the two in such a way as to manage and reduce risk while also making sure that users stay productive, and technology does not get in the way.
For example, we regularly run across customers who ask what the right action is to take with spam or bulk email. Some customers screen and quarantine large volumes of everything, including newsletters, bulk, and spam. Changing those customers to a user-accessible Junk Email folder delivery might give users more control and save costs on quarantine release, but the change could also introduce risks. If users are educated and trained properly, changing to Junk Email folder delivery could result in less costs with little additional risk; but if users aren’t sophisticated, the change could mean trouble. Conversely, quarantining everything might be too aggressive and requires too many overrides that put the organization into a risky spot. There may not even be a one-size-fits-all decision for the whole organization.
Don’t forklift your existing configuration
One of the biggest missteps we see is trying to bring rules and allow overrides over without any appreciation for what they were doing and why they were created in the first place. In most cases, the current system has been in place for years and there’s little organizational knowledge about what is essential. Instead of putting in significant effort to deeply inventory and migrate the configuration, wouldn’t it be great to get a sense of what Defender for Office 365 actually does to your messages so you can migrate only those rules and overrides that are still necessary? In other words, to see how Defender for Office 365 performs without overrides, and then only focus on the overrides that are still needed?
Perhaps more importantly, some configuration options and choices don’t translate well to a new system, and – worse – they can do harm. For example, it isn’t uncommon to see an allow override for a system that was business critical, but either is no longer essential, or which could even be vulnerable to compromise. In the past, systems were tuned for deliverability and for blocking spam; today’s threats are entirely more complicated. We believe that more complicated configurations lead to the possibility of abuse. We sometimes see a trusted email route that gets compromised or misconfigured and leads to a lot of pain. It is best to avoid overrides or rules that aren't necessary.
Yes, some tuning may still be necessary to make sure that Defender for Office 365 still delivers important business email, but a blanket override is not the way to do it. Instead, we suggest exposing Defender to Office 365 to real traffic, giving it feedback, and when necessary, creating overrides that are as targeted as narrowly as possible.
Get the Security Operations teams involved before migration
The other big mistake we often see is that the migration team doesn’t involve the security teams deeply and early enough. Instead of waiting for the MX change to occur, the best approach is to onboard the security teams early and during testing. It takes time to onboard these teams to tools like Automated Investigation & Response, Threat Explorer, and Advanced Hunting. If there are integrations with SIEM, or ITSM systems, these can also take time. Even if Defender for Office 365 only catches a small amount of malicious payload that gets through your current systems, it still gives them a chance to practice and learn how the system works in the pilot or testing phase well in advance of the MX change. If these teams don’t get the opportunity to familiarize themselves with Defender for Office 365 prior to the MX change, then the organization will have to scramble and remediation times will go up, putting the organization at risk.
How we propose that you avoid these pitfalls and build confidence
Instead of flipping an entire domain, we suggest making use of the Enhanced Filtering for Connectors feature, combined with scoping policies and actions to pilot users and groups instead of worrying about mail routing. This will allow you to use a “defense-in-depth” approach to go as fast or as slow as the organization is comfortable with. With this approach, you essentially put individual users or groups of users into active or passive Defender for Office 365 protection. We define these terms as follows:
- Passive (or “monitor”) mode - Defender for Office 365 is telling administrators what the verdicts are, but not yet taking actions that could result in false positives or confuse the users prior to rollout.
- Active mode – Defender for Office 365 not only renders a verdict but begins acting on the messages according to the configuration you’ve set. E.g., moving phish messages to quarantine.
Depending on the level of complexity you want to take on, you can not only iterate through larger groups of users, but you can also take this approach on a per-feature level. For example, you might turn on Safe Attachments quickly for the entire organization to gain additional protections, but go slower with features like Spoof Intelligence and Mailbox Intelligence until you’ve had an opportunity to tune them and configure any essential business overrides.
As you proceed, most likely your existing filtering system can also be put into a passive mode, allowing you to build up to the day when the existing system is completely removed from the mail routing path. Any time either system is in a passive mode for a user, the security response folks should generally still get alerted. Security teams can even merge the data from the two systems and focus on the misses from one or the other to get a sense of whether the systems are performing similarly and to expectations or not. Ramping up security and operations process occurs before the MX switch, making sure everyone is comfortable.
Built by experts and tested in the most complex environments
What you get with this guide is a repeatable process and template that has worked extremely well with even the most complex environments.
You get mistakes to avoid, considerations that are sometimes missed, and a plan that works. And the plan scales – you can modify it to be simple, with only a few days of tuning; or you can use it to build a 6-month plan using as many pilots, waterfalls, and phases as you need to get the organization comfortable and ready. We expect that customers who follow the document should have a much better experience migrating to Defender for Office 365.
We look forward to you trying it out and giving us feedback!
Do you have questions or feedback about Microsoft Defender for Office 365? Engage with the community and Microsoft experts in the Defender for Office 365 forum.
Posted at https://sl.advdat.com/3HgQmmn