Blog Post

Microsoft Defender for Office 365 Blog
3 MIN READ

Configurable impersonation protection and scope for Preset Security policies

UrjaGandhi's avatar
UrjaGandhi
Icon for Microsoft rankMicrosoft
May 17, 2022

We're making enhancements to Microsoft Defender for Office 365 preset security policies (namely, Strict and Standard policies)!

 

Preset security policies allow customers to apply recommended settings to their environments in a simple, templatized fashion. To learn more about preset security policies, view our documentation here. The recommended settings that comprise preset security policy setting values are also available on Microsoft Docs.

 

Apply preset Strict and Standard security policies to all users of the entire organization

SecOps teams will now be able to apply the preset security policy to all users in the entire organization. It will no longer be cumbersome to select the individual users when you want to protect all the recipients of your organization (but you can still select specific recipients)!

 

Currently in preset security policies, you separately select the recipients who receive protection by Exchange Online Protection (EOP) features and the recipients who receive protection by Defender for Office 365 features. With these updates, you can still apply the protections to separate groups of recipients, but you will also be able to simply choose an option to apply the recipients from the EOP protections to the Defender for Office 365 protections.

 

Although we don’t recommend it, you’ll still be able to exclude specific recipients from receiving the protections in preset policies.

 

Figure 1. Preset Security Policies

 

Figure 2. Exchange Online Protection (all recipients)

 

Figure 3. Defender for Office 365 (previously selected recipients/ all recipients)

 

 

Use preset security policies to configure impersonation protection sender and domain lists

 

In order to protect customers against impersonation attacks and provide stronger anti-phishing posture, preset security policies (Standard and Strict) will provide a way to configure the lists for targeted custom users and domains to protect in impersonation protection. Specific impersonation settings available in preset security policies are described here.

 

 

You’ll no longer need to disable preset security policies and create custom anti-phishing policies when all you want is Microsoft’s recommended settings and impersonation protection. This update will not only cover customers who are unknowingly missing out on impersonation protection of their key custom domains and senders, but also makes it easier for tenant admins and security operations teams to configure their anti-phishing settings using preset security policies without the need to explicitly use a custom policy.

 

Protected custom users

Add internal or external email addresses of top-level executives, board members, and other people in key roles who might be impersonated by attackers.

 

Figure 4. Impersonation protection - custom users

 

Protected custom domains

Add custom domains owned by your organization or domains that belong to your key suppliers and partners to be detected when impersonated by attackers.

Figure 5. Impersonation protection - custom domains

 

Trusted senders and domains

List individual senders and all senders in entire domains that you wish to exclude from impersonation protection and never flag them as impersonation attack. These senders will still be subject to scanning by filters other than impersonation.

Figure 6. Impersonation protection - trusted senders and domains

 

Additional information

With these enhancements, you will not be able to turn off the impersonation protection settings (for example, EnableTargetedUserProtection or EnableTargetedDomainsProtection).

Similarly, you still can’t modify the action that’s taken on messages detected as impersonation. See the actions here. (for example, TargetedUserProtectionAction, TargetedDomainProtectionAction). This behavior is similar to other protection settings in preset security policies that are currently enabled and can’t be modified. For more information, see here.

 

Impersonation protection applies to

With these latest enhancements, you’ll quickly and easily be able to use preset security policies with protection settings recommended by Microsoft.

 

Figure 7. Preset Security policy (Standard)

 

Check out these enhancements in your environment!

Well gradually roll out these capabilities starting between June and August 2022. Well communicate specific rollout dates for your tenant via Microsoft Message Center Posts. Stay tuned! We’re excited for you to try this out and give us your 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.

 

Updated May 16, 2022
Version 1.0
  • ChrisAtMaf's avatar
    ChrisAtMaf
    Steel Contributor

    Hey, love the 'Use preset security policies to configure impersonation protection sender and domain lists' feature - we would love to use these preset security policies rather than configure custom ones.

    However at present when using preset security policies it's not possible to configure any quarantine policy for the Anti-phishing or Anti-spam policies. Therefore if you want quarantine notifications to be enabled (not an unreasonable request for end users) the preset security policies are still no good.

    Please could you consider implementing this functionality as well (allowing quarantine notification emails when preset security policies are in use)?

  • AJS240's avatar
    AJS240
    Copper Contributor

    We got bitten by this and have had to disable to allow spam digest emails. MS support worked on the case, they were unfamiliar with this issue.

    SafeLinks does not work now, even with a seperate SafeLinks policy in place. MS support is working on this for us.

    It's more than a little crazy to have to turn off security features to have other features work.

  • DaveS99's avatar
    DaveS99
    Copper Contributor

    How is this different than the User impersonation protection and Domain impersonation protection configurations in the Anti-Phishing policies? looks identical and redundant if we are already implementing those there?