Exchange Online Protection (EOP) and Microsoft Defender for Office 365 (MDO) are the email and collaboration security services native to Microsoft 365. EOP is included at all levels of licensing for Exchange Online, with MDO bringing additional security capabilities to license levels such as Business Premium, Microsoft 365 E3, and Microsoft 365 E5.

In this blog, I’ll review five of the most common security mistakes I see in tenants regarding EOP and MDO. Realistically, this list could go to fifty mistakes, but I’ll focus on ones I think you can quickly convert into quick wins or just may have never crossed your mind.

It’s not new and flashy, but email remains a battleground for defender. For example, Abnormal reports that YoY, business email compromise (BEC) has increased 55%. Therefore, it’s important to minimize the number of mistakes in your environment, to keep that attack surface as low as possible, while hopefully making life easier for users.

This blog is part of a series on common Microsoft 365 security mistakes. View the previous blogs here:

Let’s crack on with reviewing common Microsoft 365 email security mistakes.

Table of Contents

Exclusions are not fine-grained

There are a ton of ways to create exclusions for inbound email filtering: mail flow rules, anti-spam policy, Tenant Allow/Block List (TABL), connection filter policy, and more. Most commonly, exclusions will allow either an email address or domain a spam filtering bypass.

In EOP, inbound email is given a spam confidence level (SCL) which is set as a header for the email. Values 5-9 mean spam of varying degree of confidence based on reasons such as DNS authentication failure, known spam patterns, etc. As an administrator, if you set up a skip spam policy, it sets the SCL to -1 (minus one) so that any spam rules are ignored.

Exclusions are a reality of security software. False positives are a thing (albeit often caused by sender misconfiguration, like bad SPF/DKIM settings). What you want to avoid are overly simplistic and broad scoped exclusions.

For example, in the default anti-spam policy (Anti-spam inbound policy (Default)), I often find common domains listed: your company’s domain, partner companies’ domains, and consumer domains such as outlook.com.

If the default policy is your only policy, or you are applying the same type of exclusion to another wide-reaching policy, you are risking an adversary completely bypassing controls that would otherwise protect them. The attacker could provision email sending infrastructure, use the allow-listed domain, and sending phishing emails or other threats. (Important note: you cannot bypass malware determinations, even by setting SCL -1).

Similar is true of the Connection filter policy, which is one of the first inbound checks email has an is based on IP allow/block lists. Just because you trust the IP now doesn’t mean you can always trust it. This is particularly the case for external parties. Just don’t do it: find the root cause and tackle that.

Let’s assume a domain is always failing anti-spam checks. Here’s some thoughts on the best way to create exclusions in a way that can reduce risk.

  • Use specific and full email addresses instead of entire domains, if possible.
  • Use mail flow rules that also confirm known markers. For example, set the SCL to -1 for a specific domain when SPF/DMARC/DKIM pass, and/or if from a known IP.
  • The tenant allow/block list forces matching sending infrastructure for spoofed senders but not quite to the same level as mail flow rules. I use TABL re-actively and mail flow rules proactively as a longer term tool.
  • Check across your infrastructure (all anti-malware/spam/phishing policies, TABL, mail flow rules, connection filter) for historic exclusions that may no longer be required.

Unused domains are not protected by DNS authentication

If you own domains but don’t send email from them, you should still use DNS authentication to let recipients know that no email received from those domains are authorized and should be treated as spam. I see lots of companies who own (park) domains and maybe even register them with Microsoft 365, but don’t then have any controls for them.

For SPF, you should be creating a record which trusts no servers:

For DMARC, set the record to reject all (100%) of failures. This is the default, but I like it explicitly laid out for visability:

Allowing end-users to control anti-spam bypasses

EOP has the concept of a safelist collection that is enabled out the box. This allows users to control their own junk email settings, similar to other email vendors such as Mimecast with their managed senders feature. If you’ve ever right clicked an email in Outlook and managed the Junk Email Options, you’ve been managing the safelist collection.

In the example above, you can see the safelist collection has allowed a user to give an anti-spam bypass to the entire gmail.com domain. While it can help users get the job done, the safelist collection by default allows users to bypass your administrator defined rules, effectively getting the SCL -1 rule for email addresses they define rather than you the security administrator.

As an admin, you can use Set-MailboxJunkEmailConfiguration to manage the safelist collection per mailbox, either by editing it or disabling it entirely (-Enabled $false). You can’t disable it tenant-wide, so use a recurring PowerShell script to sweep up any new/edited mailboxes.

Safe Attachments dynamic delivery can cause end user problems

Defender for Office 365 Plan 1 unlocks the Safe Attachments capability. This uses a sandbox environment for email attachments to ‘detonate’ them, and review the consequences of that detonation on the sandbox. If there is nothing suspicious, the attachment is delivered.

This adds a small overhead to inbound email delivery, growing as the size of the attachment grows.

To mitigate concerns administrators may have about slowing email delivery, Microsoft provide the Dynamic Delivery action. For Exchange Online mailboxes, this allows the email message to be delivered as normal, but the attachment only has a preview version, with the full version later ‘injected’ into the email.

I don’t recommend using Dynamic Delivery. Instead, stick with Block mode. One of the reasons I don’t recommend it is down to the end-user experience. Let’s take the example of an inbound Excel file that gets the preview version attached. The recipient very quickly forwards the email on to someone else. The recipient of the forwarded email will not get the full file, only the temporary placeholder. Queue support calls in 3… 2… 1….

Treating email security as one size fits all

The last common mistake we’ll cover is how uniform everything is in a lot of huge tenants I review. I will always advocate simplification of security architecture, but simplicity is good until it isn’t. EOP and MDO are highly flexible and you can target different levels of protection (and exclusions/bypasses) to different folks, based on the risk and business need. This is useful and important for any large environment

Let’s explain this with some examples:

  • If you have a partner company domain you really need to make sure always bypasses anti-spam, does it have to apply to the whole tenant?  Use mail flow conditions to refine it only to recipients who depend on communication with that domain.
  • If you don’t want to allow users the ability to manage their safelist collection, do you need to apply this to the whole organization?  Depending on your scale and other factors, it may add just too much to your central IT burden.  One option – the merits can be debated – is you allow users who do well in attack simulation training permission to manage their own, but not others.
  • You may decide the preset standard protection policy is a good baseline for your tenant. But this doesn’t mean every user has to be treated equally. You’ll have users that are higher risk, such as executives, privileged users, or others with access to sensitive resources. Why not target strict protection policies at those users, while allowing less risky users a lower degree of protection?

Conclusions

The moral of this common mistake article can be summarized as: target and refine your policies so that anything increasing the attack surface is minimized, and anything reducing the attack surface is maximized.  Don’t accept the defaults (looking at you, safelist collections), and target the standard/strict protection policies to folks depending on their risk.

Tags:
Last updated on February 2, 2024