MDE vs Intune for ASR

[PaulCDicker]

Hi All

I have a partner asking the following. Would appreciate any responses Thanks

As we discussed over the phone the vast majority of devices we manage are already enrolled in MEM (AAD Joined or Hybrid AD Joined) and therefore all of the Endpoint Security policy types are supported.   

The key challenge that we have at present is that ASR is not yet included under MDE Security Configuration even though when you create a new ASR policy the target is mdm,microsoftSense (screen clip below) which suggests to me this capability is not far away.

We have the ability to build out an ASR framework using PowerShell and our RMM tools however this requires a significant investment of time which would be a wasted effort if ASR will be included in  MDE Security Configuration in the near future.

M

https://docs.microsoft.com/en-us/mem/intune/protect/mde-security-integration#which-solution-should-i...

[#2]

If tbe devices are enrolled in MEM and if you are licensed for MDE, then you can straight away deploy ASR policies. MDE security configuration is meant for scenarios where you are not able to do a full enrollment in Intune. This also allows pushing MDE policies on servers.

[#3]

@rahuljindal-MVP Thanks for your post, this is what we have setup at present for the majority of endpoints however for servers or endpoints not managed by MEM we need to be able to use MDE to manage AV, Firewall and ASR policies.  AV/FW work as expected using the MDE/MEM Security Configuration on these devices but ASR is not yet working yet the target in the policy is defined as mdm,microsoftSense so would expect ASR policies to also work in the same way.  

[#4]

I understand. This is a limitation of MDE security configuration right now. Hopefully this can change in future.

[#5]

Thanks Guys have escalated to Australian engineering team to see if we can get anything on roadmap and timeline

[#6]

@PaulCDicker 

have the same request.

Did you get any update? 

Best regards 

[#7]

@PaulCDicker  This issue still exists for us and we have actually gone backwards.  Any device in MEM showing as MDE managed is now reporting in MDE Security Improvements as an "Exposed Device" for all 16 x ASR Security Controls.  To make matters worse the PowerShell commands we used to use on these devices to manually enable these 16 ASR commands no longer work.  We assume that this is because these devices are now enrolled in MEM using the "Use MDE to enforce security configuration settings from MEM" option which we assume either means only MEM policies can be applied to these devices or Tamper Protection is now blocking the ASR commands via PowerShell.  We have other devices enrolled in MDE but not in MEM that are showing as compliant for all 16 ASR security controls as we have successfully enabled these using PowerShell.  This is turning into a bit of a mess for hybrid environments where a reasonable number of devices are not enrolled in MEM or not Hybrid AD Joined but have are onboarded in MDE (MicrosoftSense) for EDR, TVM etc.

[#8]

I see that this is now resolved in Endpoint Manger / Endpoint Security / Attack Surface Reduction. Just create a new rule and select the top item on the list (Windows 10, Winodws 11, and Windows Server) under Platform when you create the new rule. Disable your existing one of course and then enable the new one which includes the new ASR rule selection for "Bock abuse of exploited vulnerable signed drivers." I am not sure when that showed up but it is there now.

[#9]

@Jim Hill The problem is that we use Graph API to deploy this policy, but we can't do the same for the new mdm,ms.sense policy for (Windows 10,11 and Windows Server)
Apparently this new type doesn't have an API yet ??

[#10]

I am not sure about that. Please report back if you find out anything more on this.