Exclusions in Attack Surface Reduction rules in Block mode

[Kiril]

We configured all ASR rules to "Audit mode" to see what would have been blocked in the last few days. The following rules stick out:

Block Office communication application from creating child processes: here basically one app (detected file is a pdf reader) creates a few hundred detections per day. This pdf reader app is triggered by Outlook (source app) in 99% of the cases. I assume this is because opening attachments in an email opens the pdf reader. This does not look malicious. Am I right to assume that I should white list the app before enabling this rule in "Block mode"? Also: should Outlook or the pdf reader be added to the exclusions?

Block credential stealing from the Windows local security authority subsystem (lsass.exe): a few hundred detections happen here by all kinds of source apps (e.g. Taskmgr.exe, DropboxUpdate.exe,

svchost.exe, ...). Detected file is lsass.exe. Is there anything to whitelist here, or should I just enable the rule in "Block mode"? What will the impact on the user machine look like?

Block Office applications from injecting code into other processes: only office applications  are listed as source app (Word, Excel, PowerPoint), but the detected file is always a specific document, e.g. Document1.xlsx or PowerPoint2.pptx. There are like 30 detections in the last week. What action is exactly causing an office application to inject code into other processes? Is it safe to enable this rule in "Block mode"?

Block executable files from running unless they meet a prevalence, age, or trusted list criteria: here I can see detections when users are installing something on their machine, e.g. Setup.exe or Webex.exe. I understand, that if I enable this rule, those installations will fail. How should I define trusted list criteria in order to allow some of those executables? I cannot just whitelist C:\Users\User1\Desktop\Setup.exe because I don't know how the names of all those Setup.exe files are called. What method is there to define which executable is allowed? 

[#2 · Accepted solution]

I didn't have the answers you were looking for but you sparked my interest. So far, the best resource I found to get some more info (and advice) on these rules was Palantir's blog:
https://blog.palantir.com/microsoft-defender-attack-surface-reduction-recommendations-a5c7d41c3cf8

Hopefully it helps you form an opinion for your own situation.

[#3]

@NielsScheffers 

Thank you, that blog post is indeed very insightful. We managed to boil it down to two rules, which we currently need in "Audit mode":

Block Office communication application from creating child processes: we are monitoring this one, and are quite optimistic to gather enough data to white list all applications, which are getting detected.

Block executable files from running unless they meet a prevalence, age, or trusted list criteria: This rules indeed can be very annoying. You cannot foresee what needs to be white listed. There might be an approach to white list a specific folder, which is allowed to execute *.exe, e.g. for installing new software, but that won't work if you want to trigger some other blocked application. It could work, if there was some sort of privilege or admin role which could be assigned temporary, where a user can install an application under the supervision of an admin. But for now this will stay in "Audit mode".

[#4]

@Kiril, there are several solutions for elevated user sessions like that.

In your case, you could use Privileged Access Management to give your admins (temporary) local privileges, so they can guide the user. If you want the user to do this autonomously, you can check this post on my blog (https://threeisacloud.tech/power-to-the-user/) or, depending on your requirements, look for more compliant solutions than mine :).

[#5]

Interesting blog post, thank you! Will take a look into PAM.