Updates to .Net and COM topic areas plus changes for windows resiliency

windows/security/application-security/application-control/app-control-for-business/design/allow-com-object-registration-in-appcontrol-policy.md

@@ -16,10 +16,8 @@ The [Microsoft Component Object Model (COM)](/windows/desktop/com/the-component-
 
 App Control for Business enforces a built-in allowlist for COM object registration. While this list works for most common application usage scenarios, you might need to allow more COM objects to support the apps used in your organization. You can specify allowed COM objects via their GUID in your App Control policy as described in this article.
 
-> [!IMPORTANT]
+> [!WARNING]
-> When any App Control for Business policy with option **0 - Enabled:UMCI** is enforced on a device, .NET adds an extra validation check before running COM objects. The check verifies the COM object's system registration matches the code being run. If there is a mismatch between the GUID calculated by .NET and the GUID stored in the COM registration, .NET won't load the object and the user sees a general error dialog informing them about the failure. This mitigates certain COM-based attacks which could otherwise be used to run an attacker's own malicious or vulnerable payload.
+> When App Control is enforced, .NET doesn't load certain COM objects if their registration GUID doesn't match the one calculated by the system at runtime. When that happens, the user sees a general COM load error dialog, but no events or other information is logged to the system. The COM allowlist mechanism described in this article **doesn't affect .NET's GUID validation check for COM objects** leaving those .NET apps incompatible with App Control at this time. For more information, see [App Control Admin Tips & Known Issues: .NET doesn't load COM objects with mismatched GUIDs](../operations/known-issues.md#net-doesnt-load-component-object-model-com-objects-with-mismatched-guids)
->
-> The COM allow list mechanism described in this article **doesn't affect .NET's GUID validation check for COM objects**. Any .NET app attempting to run a COM object with a mismatched GUID are thus incompatible with App Control at this time. There are no policy control options to manage the GUID verification check, meaning the check is always performed. If you see COM object failures after an App Control policy is deployed, contact the software developer or the Independent Software Vendor (ISV) who produces the app to request a fix for the issue.
 
 ### Get COM object GUID
 
@@ -130,7 +128,7 @@ To add this CLSID to the existing policy, follow these steps:
     PS C:\WINDOWS\system32> Set-CIPolicySetting -FilePath <path to policy xml>\AppControl_policy.xml -Key "{f8d253d9-89a4-4daa-87b6-1168369f0b21}" -Provider WSH -Value true -ValueName EnterpriseDefinedClsId -ValueType Boolean
     ```
 
-    Once the command has run, find the following section added to the policy XML.
+    Once the command runs, find the following section added to the policy XML.
 
     ```XML
     <Settings>

windows/security/application-security/application-control/app-control-for-business/design/appcontrol-and-dotnet.md

@@ -2,43 +2,46 @@
 title: App Control for Business and .NET
 description: Understand how App Control and .NET work together and use Dynamic Code Security to verify code loaded by .NET at runtime.
 ms.localizationpriority: medium
-ms.date: 09/11/2024
+ms.date: 02/13/2025
 ms.topic: conceptual
 ---
 
 # App Control for Business and .NET
 
+> [!WARNING]
+> When App Control is enforced, .NET doesn't load certain Component Object Model (COM) objects if their registration GUID doesn't match the one calculated by the system at runtime. When that happens, the user sees a general COM load error dialog, but no events or other information is logged to the system. For more information, see [App Control Admin Tips & Known Issues: .NET doesn't load COM objects with mismatched GUIDs](../operations/known-issues.md#net-doesnt-load-component-object-model-com-objects-with-mismatched-guids)
+
 .NET apps (as written in a high-level language like C#) are compiled to an Intermediate Language (IL). IL is a compact code format that can be supported on any operating system or architecture. Most .NET apps use APIs that are supported in multiple environments, requiring only the .NET runtime to run. IL needs to be compiled to native code in order to execute on a CPU, for example Arm64 or x64. When .NET compiles IL to native image (NI) on a device with an App Control user mode policy, it first checks whether the original IL file passes the current App Control policies. If so, .NET sets an NTFS extended attribute (EA) on the generated NI file so that App Control knows to trust it as well. When the .NET app runs, App Control sees the EA on the NI file and allows it.
 
-The EA set on the NI file only applies to the currently active App Control policies. If one of the active App Control policies is updated or a new policy is applied, the EA on the NI file is invalidated. The next time the app runs, App Control will block the NI file. .NET handles the block gracefully and falls back to the original IL code. If the IL still passes the latest App Control policies, then the app runs without any functional impact. Since the IL is now being compiled at runtime, you might notice a slight impact to performance of the app. When .NET must fall back to IL, .NET will also schedule a process to run at the next maintenance window to regenerate all NI files, thus reestablishing the App Control EA for all code that passes the latest App Control policies.
+The EA set on the NI file only applies to the currently active App Control policies. If one of the active App Control policies is updated or a new policy is applied, the EA on the NI file is invalidated. The next time the app runs, App Control will block the NI file. .NET handles the block gracefully and falls back to the original IL code. If the IL still passes the latest App Control policies, then the app runs without any functional issue. Since the IL is now being compiled at runtime, you might notice a slight reduction in performance of the app. When .NET must fall back to IL, .NET will also schedule a process to run at the next maintenance window to regenerate all NI files, thus reestablishing the App Control EA for all code that passes the latest App Control policies.
 
 In some cases, if an NI file is blocked, you might see a "false positive" block event in the *CodeIntegrity - Operational* event log as described in [App Control Admin Tips & Known Issues](../operations/known-issues.md#net-native-images-may-generate-false-positive-block-events).
 
-To mitigate any performance impact caused when the App Control EA isn't valid or missing:
+To mitigate any performance reduction caused when the App Control EA isn't valid or is missing:
 
 - Avoid updating the App Control policies often.
 - Run `ngen update` (on all machine architectures) to force .NET to regenerate all NI files immediately after applying changes to your App Control policies.
 - Migrate applications to .NET Core (.NET 6 or greater).
 
-## App Control and .NET hardening
+## App Control and .NET Dynamic Code Security hardening
 
-Security researchers found that some .NET capabilities that allow apps to load libraries from external sources or generate new code at runtime can be used to circumvent App Control controls.
+Security researchers found that some .NET capabilities that allow apps to load libraries from external sources or generate new code at runtime can be used to circumvent App Control. To address this potential vulnerability, App Control includes an option called *Dynamic Code Security* that works with .NET to verify code loaded at runtime.
-To address this potential vulnerability, App Control includes an option called *Dynamic Code Security* that works with .NET to verify code loaded at runtime.
 
-When the Dynamic Code Security option is enabled, the App Control policy is applied to libraries that .NET loads from external sources. For example, any remote sources, such as the internet or a network share.
+When Dynamic Code Security is enabled, your App Control policy is applied to libraries that .NET loads from external or remote sources, like the internet or a network share. It also detects tampering in code generated to disk by .NET and blocks loading code that is tampered. Additionally, some .NET loading features not supported with Dynamic Code Security, including loading unsigned assemblies built with System.Reflection.Emit, are always blocked.
+
+Usually, when dynamic code is blocked, its parent process is stopped or crashes. To prevent this using ASP.NET, you can precompile the dynamic code for deployment only. See ["Precompiling for Deployment Only" in the ASP.NET Precompilation Overview](/previous-versions/aspnet/bb398860(v=vs.100)#precompiling-for-deployment-only).
 
 > [!IMPORTANT]
-> .Net dynamic code security hardening is *turned on and enforced* if any App Control policy with UMCI enabled has set option **19 Enabled:Dynamic Code Security**. There is no audit mode for this feature. You should test your apps with this option set before turning it on across large numbers of devices.
+> .NET Dynamic Code Security works in audit mode only on Windows 11 24H2 and later, and Windows Server 2025 and later. There's no audit mode for Dynamic Code Security on Windows 10, or on earlier versions of Windows 11 and Windows Server. If any App Control policy sets option **19 Enabled:Dynamic Code Security** on those earlier versions, then dynamic code security hardening is *turned on and enforced* even if the policy is in audit mode. Always test your apps thoroughly and  use safe deployment practices when deploying app control policies to production.
 
-Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that was tampered with.
+Dynamic Code Security mitigates potential attack techniques often referred to as "second order" attacks. That means that the attacker has access to the system and is able to run code. The second order attacks might be attempts to gain persistence or further obscure the attackers activities. Although Dynamic Code Security is important and recommended, Microsoft also recommends testing the policy in audit mode on systems running Windows 11 24H2 and later, or Windows Server 2025 and later before you enforce it.
 
-Dynamic Code Security isn't enabled by default because existing policies might not account for externally loaded libraries.
+Code blocked by Dynamic Code Security is logged using event ID 3114 in the **CodeIntegrity - Operational** event log. Except for code loaded using one of the unsupported .NET features like System.Reflection.Emit, you can create rules to allow blocked dynamic code using information from the events. See [Use the App Control Wizard to create rules from the App Control Event Logs](./appcontrol-wizard-parsing-event-logs.md).
-Additionally, a few .NET loading features, including loading unsigned assemblies built with System.Reflection.Emit, aren't currently supported with Dynamic Code Security enabled.
-Microsoft recommends testing Dynamic Code Security in audit mode before enforcing it to discover whether any new libraries should be included in the policy.
 
-Additionally, customers can precompile for deployment only to prevent an allowed executable from being terminated because it tries to load unsigned dynamically generated code. See the "Precompiling for Deployment Only" section in the [ASP.NET Precompilation Overview](/previous-versions/aspnet/bb398860(v=vs.100)) document for how to fix that.
+> [!NOTE]
+> .NET attempts two different methods to run dynamically generated code. If your App Control policy blocks the first method, .NET tries the second one. Each of the two attempts raises a distinct 3114 event. When a 3114 event occurs in isolation, it's safe to ignore as a "false positive" because it only covers the first attempt by .NET to run the code. Only when you see two 3114 events back-to-back within milliseconds for the same code does it indicate an actual issue to review.
 
-To enable Dynamic Code Security, add the following option to the `<Rules>` section of your App Control policy:
+To enable Dynamic Code Security, add option **19 - Enabled:Dynamic Code Security** to your App Control policy using the App Control Wizard, the set-ruleoption PowerShell cmdlet, or by adding the following to the `<Rules>` section of your App Control policy XML:
 
 ```xml
 <Rule>

windows/security/application-security/application-control/app-control-for-business/design/create-appcontrol-policy-for-lightly-managed-devices.md

@@ -12,8 +12,8 @@ ms.date: 02/07/2025
 
 This article describes how to create an App Control for Business policy using the Smart App Control policy as a template. [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) is an app control-based security solution designed for consumer users. It uses the same technology as App Control for Business so it's easy to use as the basis for an equally robust but flexible enterprise policy. 
 
-> [!INFORMATION]
+> [!NOTE]
-> We strongly recommend the policy created in this article as the ideal starter policy for most App Control deployments to end user's devices. Typically, organizations that are new to App Control will be most successful if they start with a permissive policy like the one described in this article. Organizations can choose to harden the policy over time to achieve a stronger overall security posture on their App Control-managed devices as described in later articles.
+> Microsoft recommends the policy created in this article as the ideal starter policy for most App Control deployments to end user's devices. Typically, organizations who are new to App Control will be most successful if they start with a permissive policy like the one described in this article. You can choose to harden the policy over time to achieve a stronger overall security posture on your App Control-managed devices as described in later articles.
 
 As in [App Control for Business deployment in different scenarios: types of devices](common-appcontrol-use-cases.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of App Control to prevent unwanted or unauthorized applications from running on their managed devices.
 

windows/security/application-security/application-control/app-control-for-business/operations/known-issues.md

@@ -2,7 +2,7 @@
 title: App Control Admin Tips & Known Issues
 description: App Control Known Issues
 ms.manager: jsuther
-ms.date: 09/11/2024
+ms.date: 02/13/2025
 ms.topic: troubleshooting
 ms.localizationpriority: medium
 ---
@@ -28,21 +28,21 @@ For **single policy format App Control policies**, in addition to the two preced
 - <OS Volume>\\Windows\\System32\\CodeIntegrity\\SiPolicy.p7b
 
 > [!NOTE]
-> A multiple policy format App Control policy using the single policy format GUID `{A244370E-44C9-4C06-B551-F6016E563076}` may exist under any of the policy file locations.
+> A multiple policy format App Control policy using the single policy format GUID `{A244370E-44C9-4C06-B551-F6016E563076}` might exist under any of the policy file locations.
 
 ## File Rule Precedence Order
 
 When the App Control engine evaluates files against the active set of policies on the device, rules are applied in the following order. Once a file encounters a match, App Control stops further processing.
 
-1. Explicit deny rules - a file is blocked if any explicit deny rule exists for it, even if other rules are created to try to allow it. Deny rules can use any [rule level](../design/select-types-of-rules-to-create.md#app-control-for-business-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
+1. Any file matching an explicit deny rule is blocked, even if you create other rules to try to allow it. Deny rules can use any [rule level](../design/select-types-of-rules-to-create.md#app-control-for-business-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
 
-2. Explicit allow rules - if any explicit allow rule exists for the file, the file runs.
+2. Any file matching an explicit allow rule runs.
 
-3. App Control then checks for the [Managed Installer extended attribute (EA)](../design/configure-authorized-apps-deployed-with-a-managed-installer.md) or the [Intelligent Security Graph (ISG) EA](../design/use-appcontrol-with-intelligent-security-graph.md) on the file. If either EA exists and the policy enables the corresponding option, then the file is allowed.
+3. Any file that has a [Managed Installer](../design/configure-authorized-apps-deployed-with-a-managed-installer.md) or [Intelligent Security Graph (ISG)](../design/use-appcontrol-with-intelligent-security-graph.md) extended attribute (EA) runs if the policy enables the matching option (managed installer or ISG).
 
-4. Lastly, App Control makes a cloud call to the ISG to get reputation about the file, if the policy enables the ISG option.
+4. Any file that isn't allowed based on the preceding conditions, is checked for reputation using the ISG when that option is enabled in the policy. The file runs if the ISG decides that it's safe and a new ISG EA is written on the file.
 
-5. Any file not allowed by an explicit rule or based on ISG or MI is blocked implicitly.
+5. Any file not allowed by an explicit rule, or based on ISG or managed installer, is blocked implicitly.
 
 ## Known issues
 
@@ -51,11 +51,11 @@ When the App Control engine evaluates files against the active set of policies o
 Until you apply the Windows security update released on or after April 9, 2024, your device is limited to 32 active policies. If the maximum number of policies is exceeded, the device bluescreens referencing ci.dll with a bug check value of 0x0000003b. Consider this maximum policy count limit when planning your App Control policies. Any [Windows inbox policies](inbox-appcontrol-policies.md) that are active on the device also count towards this limit. To remove the maximum policy limit, install the Windows security update released on, or after, April 9, 2024 and then restart the device. Otherwise, reduce the number of policies on the device to remain below 32 policies.
 
 > [!NOTE]
-> The policy limit was not removed on Windows 11 21H2, and will remain limited to 32 policies.
+> The policy limit wasn't removed on Windows 11 21H2, and remains limited to 32 policies.
 
 ### Audit mode policies can change the behavior for some apps or cause app crashes
 
-Although App Control audit mode is designed to avoid impact to apps, some features are always on/always enforced with any App Control policy that turns on user mode code integrity (UMCI) with the option **0 Enabled:UMCI**. Here's a list of known system changes in audit mode:
+Although App Control audit mode is designed to avoid any effect on apps, some features are always on/always enforced with any App Control policy that turns on user mode code integrity (UMCI) with the option **0 Enabled:UMCI**. Here's a list of known system changes in audit mode:
 
 - Some script hosts might block code or run code with fewer privileges even in audit mode. See [Script enforcement with App Control](../design/script-enforcement.md) for information about individual script host behaviors.
 - Option **19 Enabled:Dynamic Code Security** is always enforced if any UMCI policy includes that option. See [App Control and .NET](../design/appcontrol-and-dotnet.md#app-control-and-net-hardening).
@@ -64,6 +64,16 @@ Although App Control audit mode is designed to avoid impact to apps, some featur
 
 In some cases, the code integrity logs where App Control for Business errors and warnings are written include error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image falls back to its corresponding assembly and .NET regenerates the native image at its next scheduled maintenance window.
 
+### .NET doesn't load Component Object Model (COM) objects with mismatched GUIDs
+
+COM objects make it easy for different software components to communicate and work together. To be used by another component, COM objects must be registered with the operating system. The registration includes a GUID that is calculated based on the object's code. Loading and activation of the COM object is done using another part of the registration called the type name. Sometimes a mismatch exists between the registered GUID and the actual GUID of the activated COM object's code. Mismatches might come from bugs in the app's COM object registration code or if the COM object's code is changed in a way that affects the GUID. Normally, Windows and .NET are forgiving about this condition and runs the COM object’s code regardless. But allowing COM objects to load where there are GUID mismatches leaves the system vulnerable to attackers who can exploit the GUID confusion to run unintended code.
+
+To increase App Control's protective effectiveness on a system vulnerable to this attack technique, .NET applies an extra validation to check that the registered COM object GUID matches the system calculated one. If a mismatch is found, .NET doesn't load the COM object and a general COM load error is raised. Apps using COM objects with this condition might behave in unexpected ways and must be updated to fix issues with the app's COM object registration code.
+
+Since this behavior only occurs when App Control policy is enforced on user mode code, you can't detect it while in audit mode. There's no logging or other events when a COM object fails to load due to the extra validation check. Repairing or reinstalling the app can resolve the issue temporarily, but an app update is needed to fix the COM registration issue and prevent future instances of the problem.
+
+There are no policy control options to manage .NET's GUID verification check, meaning the check is always performed. If you see COM object failures after an App Control policy is deployed, contact the software developer or the Independent Software Vendor (ISV) who produces the app to request a fix for the issue.
+
 ### Signatures using elliptical curve cryptography (ECC) aren't supported
 
 App Control signer-based rules only work with RSA cryptography. ECC algorithms, such as ECDSA, aren't supported. If App Control blocks a file based on ECC signatures, the corresponding 3089 signature information events show VerificationError = 23. You can authorize the files instead by hash or file attribute rules, or using other signer rules if the file is also signed with signatures using RSA.