Windows-itpro-docs: ISG and/or

[Air-Git]

It is implied that ISG authorization only applies to apps that are not already explicitly authorised. But I don't see an explicit reference to that.
In Intune, there is a template to enable ISG authorization; but there are no templates for any other WDAC policy. So, if I implement the Intune policy for WDAC, does that mean it will immediately block any Microsoft app that does not have a good reputation? E.g. I found that it blocked Windows Defender Definition updates.
Does the ISG policy in any way interact with AppLocker rules dynamically? For example, if I have an AppLocker rule to allow any Adobe product, would ISG still cause an Adobe app to fail if it did not have a good reputation? E.g. I found that ISG blocks Adobe ARM updates.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 2586cc9a-d449-97cf-8164-c2e4bbed7c1e
• Version Independent ID: d606e2a2-465e-6d45-62dd-d57ff85b6a1a
• Content: Deploy Windows Defender Application Control with Intelligent Security Graph (ISG) (Windows 10)
• Content Source: windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md
• Product: w10
• Technology: windows
• GitHub Login: @mdsakibMSFT
• Microsoft Alias: justinha

[e0i]

@officedocsbot assign @e0i

[e0i]

@Air-Git

The issues section of this repository is intended for documentation and content related issues.

Please open a support ticket via the link below so that that your question gets answered quickly.

Windows 10 Support

Thank you.

[Air-Git]

I did not raise the question to obtain support. My question was intended to highlight a potential lack of clarity in the documentation viz. the default Intune policy will in fact block essential Microsoft updates to Windows Defender. It is not clear what the user is supposed to do when these are blocked.

[e0i]

@Air-Git Thank you for following-up with clarification.

The issue has been noted and the document will be revised in the light of your feedback.

[lindspea]

@Air-Git Thank you for pointing this out and helping improve MS Docs. I'll do some investigating and get back to you soonest. In the meantime is there anything you could suggest to be added to the article to help users in this instance?

[Air-Git]

The two things that need to be clarified in the document are:
1) Precedence. If I have a policy that allows an app, and I have a rule that uses ISG, which takes precedence if the app is explicitly allowed but does not have a good reputation?
2) If I use the ISG rule, and if an essential app is blocked (e.g. Defender updates) what is the action I should take?

[lindspea]

@Air-Git with regards to the second question I have found the following information. Hope this helps. In order to enable trust for executables based on classifications in the ISG, the Enabled:Intelligent Security Graph authorization option must be specified in the WDAC policy. This can be done with the Set-RuleOption cmdlet. In addition, it is recommended from a security perspective to also enable the Enabled:Invalidate EAs on Reboot option to invalidate the cached ISG results on reboot to force rechecking of applications against the ISG. Since the ISG relies on identifying executables as being known good, there are cases where it may classify legitimate executables as unknown, leading to blocks that need to be resolved either with a rule in the WDAC policy, a catalog signed by a certificate trusted in the WDAC policy or by deployment through a WDAC managed installer. Typically, this is due to an installer or application using a dynamic file as part of execution. These files do not tend to build up known good reputation. Auto-updating applications have also been observed using this mechanism and may be flagged by the ISG. Modern apps are not supported with the ISG heuristic and will need to be separately authorized in your WDAC policy. As modern apps are signed by the Microsoft Store and Microsoft Store for Business. It is straightforward to authorize modern apps with signer rules in the WDAC policy. Enabled:Intelligent Security Graph Authorization -> Use this option to automatically allow applications with "known good" reputation as defined by Microsoft’s Intelligent Security Graph (ISG). Enabled:Invalidate EAs on Reboot -> When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically re-validate the reputation for files that were authorized by the ISG.
I'm still researching the precedence issue. Will revert as soon as I find the answer

[Air-Git]

Yes, this is what it says in the documents.
The key point is this: "Since the ISG relies on identifying executables as being known good, there are cases where it may classify legitimate executables as unknown, leading to blocks that need to be resolved either with a rule in the WDAC policy, a catalog signed by a certificate trusted in the WDAC policy or by deployment through a WDAC managed installer.".
A) We assume that a rule that explicitly allows an application will take precedence over the ISG rule that does not allow it
B) This means the policy is unworkable in Intune, where there is no option to add rules to the template that enables ISG.
I think the solution is that, in almost any circumstance, you would need to build a custom WDAC policy, that would include ISG if desired.

[lindspea]

@Air-Git Thank you for this. Could I add your notes in the article for clarity for other users?

[Air-Git]

Yes, certainly, anything that helps understanding.
The products are great, and the documentation is mostly accurate. But sometimes, when implementing, there are important aspects not covered in the documentation. For example, the AppLocker CSP does not contain the Managed Installer rule referred to in the WDAC documentation. I have an open case with MS to clarify this.

[e0i]

@Air-Git

With the help of your feedback, the issue has been reviewed and an update to the documentation has been published. Thanks for your feedback.