Enabling Tamper Protection with Tenant Attach

[ryanm7687]

I am trying to determine how, if possible, to enable Tamper Protection but the various combination of current portals, features, and their preview/production status is making it difficult to follow.  Most of my confusion is from how Tamper Protection will affect my current method of deploying policies and where those policies need to come from to work with Tamper Protection.

My devices are domain joined, managed by Configuration Manager 2111, and are being uploaded into Endpoint Manager through Tenant Attach.  Tenant Attach was recently enabled for Endpoint Analytics but it is not configured with any co-management.

CM is onboarding devices to Defender for Endpoint using "Microsoft Defender for Endpoint Policies", except for where we are manually using the preview installer (not MMA method) on down-level Windows Server 2012 R2 and 2016 devices.

I am not using the "Enable security setting management" preview feature in the Microsoft 365 Defender portal under Settings, Endpoints, Enforcement Scope since that states it is for devices not yet enrolled in MEM.

CM antimalware policies are used to target various device collections and define scan schedules, exclusions, and all other available settings.  Group policy is used to configure Attack Surface Reduction rules and exclusions.

1. My understanding is that I will need to change the policies currently being applied through CM antimalware policy and group policy ASR rules into a cloud source so that Tamper Protection does not cause them to be ignored - is that correct?

 2.  Assuming the answer to #1 is "yes", where/how is the best place to redefine these policies in this situation?  Do I enable my CM device collections available for assigning policies through MEM admin center (CM device collection properties, Cloud Sync tab) and then recreate my CM antimalware policies in MEM portal to achieve the same result except I could then enable Tamper Protection?

https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/prevent-changes-to-securit...

[#2]

You should be able to assign a tamper protection directly against a collection enabled for cloud sync through tenant attach. Just use the relevant profile that you should be able to find under Endpoint security AV. You can continue using rest of the Defender policies through ConfigMgr.

[#3]

Thanks, I can confirm that I've been able to deploy Tamper Protection and policies in this way. Also, I've been able to enable Tamper Protection through the Microsoft 365 Defender portal. But either way, won't Tamper Protection being turned on cause my CM antimalware policies from being ignored because of how CM applies those policies?

[#4]

Rest of the Defender policies should continue to apply from ConfigMgr. Are you seeing otherwise?

[#5]

The policies do apply as shown in Get-MpPreference and Get-MPComputerStatus. I guess the way that Tamper Protection is described in that it ignores registry and group policy changes, my understanding was that ConfigMgr antimalware policies would also be ignored because of how they apply.

So just to confirm, the ConfigMgr antimalware policies should be 100% compatible and configurable when using Tamper Protection? Does it matter whether Tamper Protection is enabled through MEM via Tenant Attach, or instead through the Microsoft 365 Defender portal?

[#6]

I've found Windows Defender event ID 5013, which gets logged every time Tamper Protection blocks a change from taking place. With that getting shipped into my central logging I can see that ConfigMgr antimalware policies are causing this to trigger with every group policy refresh, with messages such as:

Tamper Protection Ignored a change to Microsoft Defender Antivirus.
Value: HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\real-time protection\DisableOnAccessProtection = 0x0()

I'm now switching the test back to get its antimalware policies from MEM, to see if that change the number or frequency of 5013 events. But this seems to indicate that ConfigMgr antimalware policies, or at least some of them, are not compatible with the user of Tamper Protection.

[#7 · Accepted solution]

I don't think it means that policies are not applying. Have you tried simulating any attacks to test for the policies? Do you see any events being reported in Eventvwr or Advanced hunting for the same?

[#8]

I was able to generate event ID 5013 and verify the attempt was unsuccessful, using the below commands.

Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableIOAVProtection $true -DisableEmailScanning $true -DisableBlockAtFirstSeen $true

I also tried wiping all existing definitions with the other command below. Unlike the above 2 tests, this command returns an error and does not log any Event Viewer events. None of these tests resulted in Microsoft 365 Defender incidents or alerts.

& "$ENV:ProgramFiles\Windows Defender\MpCmdRun.exe" -RemoveDefinitions -All

I believe my issue with the 5013 events appearing is from my ConfigMgr antimalware policies also applying to the test device, which lines up with:
https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/prevent-changes-to-securit....

When policies are defined through MEM with Tenant Attach they are taking priority over ConfigMgr, but every gpupdate causes around 25 instances of event 5013 and I believe that would be from the ConfigMgr policies attempting to apply. We have our registry-based group policy settings defined to full reapply at each refresh, and not only when there is a change.

After all of this, my main source of confusion is - how and where can we define and update policies (scheduled scans, exceptions, etc.) when Tamper Protection is enabled? Does that answer change depending on where/how Tamper Protection gets enabled?

[#9]

If I understand this correctly then I think the problem here is that you have multiple policy providers. Why not deploy all Defender policies using ConfigMgr and tamper protection using tenant attach?

[#10]

My only concern with that has been the 5013 events "Tamper Protection Ignored a change to Microsoft Defender Antivirus", and this still occurs even when only ConfigMgr policies are applied.

After going through each of the events I do not see any cases where we're trying to actually change a setting that Tamper Protection protects. The event must be happening because ConfigMgr is trying to write those registry values, even though they would match what is already there.

My initial concern about not being able to apply ConfigMgr antimalware policies looks to be answered. It can apply them, just that it will also attempt to apply configurations that Tamper Protection will prevent and log the 5013 events even if you are just duplicating the secure defaults Tamper Protection is trying to protect. And there appears to way to have ConfigMgr antimalware policies apply without generating the event so it becomes known, but expected behavior instead of something that could more reliably be alerted on.