Fixes #11419 - Fix statement about logic of ConfirmImpact (#11421)

* Reorg security docs and add more WDAC content

* fix broken links

* Fix statement about logic of ConfirmImpact

* Fix merge conflict

* Reflow

Author: sdwheeler

reference/docs-conceptual/developer/cmdlet/users-requesting-confirmation.md

@@ -1,6 +1,6 @@
 ---
 description: Users Requesting Confirmation
-ms.date: 09/30/2021
+ms.date: 09/24/2024
 ms.topic: reference
 title: Users Requesting Confirmation
 ---
@@ -9,23 +9,22 @@ title: Users Requesting Confirmation
 When you specify a value of `true` for the `SupportsShouldProcess` parameter of the Cmdlet attribute
 declaration, the **Confirm** parameter is added to the parameters of the cmdlet.
 
-In the default environment, users can specify the **Confirm** parameter or `"-Confirm:$true` so that
-confirmation is requested when the `ShouldProcess()` method is called. This forces confirmation
-regardless of the impact level setting.
+In the default environment, users can specify the **Confirm** parameter so that confirmation is
+requested when the `ShouldProcess()` method is called. This forces confirmation regardless of the
+impact level setting.
 
 If **Confirm** parameter is not used, the `ShouldProcess()` call requests confirmation if the
-`$ConfirmPreference` preference variable is equal to or greater than the `ConfirmImpact` setting of
-the cmdlet or provider. The default setting of `$ConfirmPreference` is **High**. Therefore, in the
-default environment, only cmdlets and providers that specify a high-impact action request
-confirmation.
+`ConfirmImpact` setting is equal to or greater than the `$ConfirmPreference` preference variable.
+The default setting of `$ConfirmPreference` is **High**. Therefore, in the default environment, only
+cmdlets and providers that specify a high-impact action request confirmation.
 
 If **Confirm** is explicitly set to false (`-Confirm:$false`), the cmdlet runs without prompting for
 confirmation and the `$ConfirmPreference` shell variable is ignored.
 
 ## Remarks
 
 - For cmdlets and providers that specify `SupportsShouldProcess`, but not `ConfirmImpact`, those
-  actions are handled as "medium impact" actions, and they will not prompt by default. Their impact
+  actions are handled as `Medium` impact actions, and they will not prompt by default. Their impact
   level is less than the default setting of the `$ConfirmPreference` preference variable.
 
 - If the user specifies the `Verbose` parameter, they will be notified of the operation even if they

reference/docs-conceptual/security/app-control/application-control.md

@@ -31,8 +31,8 @@ For more information about AppLocker and WDAC, see [Application Controls for Win
 
 ## WDAC policy enforcement
 
-When PowerShell runs under a WDAC policy, its behavior changes based on the defined security
-policy. Under a WDAC policy, PowerShell runs trusted scripts and modules allowed by the policy in
+When PowerShell runs under a WDAC policy, its behavior changes based on the defined security policy.
+Under a WDAC policy, PowerShell runs trusted scripts and modules allowed by the policy in
 `FullLanguage` mode. All other scripts and script blocks are untrusted and run in
 `ConstrainedLanguage` mode. PowerShell throws errors when the untrusted scripts attempt to perform
 actions that aren't allowed in `ConstrainedLanguage` mode. It can be difficult to know why a script
@@ -41,9 +41,9 @@ failed to run correctly in `ConstrainedLanguage` mode.
 ## WDAC policy auditing
 
 PowerShell 7.4 added a new feature to support WDAC policies in **Audit** mode. In audit mode,
-PowerShell runs the untrusted scripts in `ConstrainedLanguage` mode without errors, but logs messages
-to the event log instead. The log messages describe what restrictions would apply if the policy were
-in **Enforce** mode.
+PowerShell runs the untrusted scripts in `ConstrainedLanguage` mode without errors, but logs
+messages to the event log instead. The log messages describe what restrictions would apply if the
+policy were in **Enforce** mode.
 
 ## History of changes
 
@@ -54,9 +54,10 @@ described in the later versions include those from earlier versions.
 
 ### Changes in PowerShell 7.4
 
-On Windows, when PowerShell runs under a Windows Defender Application Control (WDAC) policy, its behavior changes based on the defined security policy. Under a WDAC policy, PowerShell runs
-trusted scripts and modules allowed by the policy in `FullLanguage` mode. All other scripts and
-script blocks are untrusted and run in `ConstrainedLanguage` mode. PowerShell throws errors when the
+On Windows, when PowerShell runs under a Windows Defender Application Control (WDAC) policy, its
+behavior changes based on the defined security policy. Under a WDAC policy, PowerShell runs trusted
+scripts and modules allowed by the policy in `FullLanguage` mode. All other scripts and script
+blocks are untrusted and run in `ConstrainedLanguage` mode. PowerShell throws errors when the
 untrusted scripts attempt to perform disallowed actions. It's difficult to know why a script fails
 to run correctly in `ConstrainedLanguage` mode.
 
@@ -67,7 +68,8 @@ throwing errors. The log messages describe what restrictions would apply if the
 
 ### Changes in PowerShell 7.3
 
-- PowerShell 7.3 now supports the ability to block or allow PowerShell script files via the WDAC API.
+- PowerShell 7.3 now supports the ability to block or allow PowerShell script files via the WDAC
+  API.
 
 ### Changes in PowerShell 7.2
 

reference/docs-conceptual/security/app-control/how-to-use-wdac.md

@@ -10,8 +10,8 @@ can configure the policy to enforce or audit the policy's rule. In audit mode, P
 doesn't change but it logs Event ID 16387 messages to the `PowerShellCore/Analytic` event log. In
 enforcement mode, PowerShell applies the policy's restrictions.
 
-This article assumes you're using a test machine so that you can test PowerShell behavior
-under a machine wide WDAC policy before you deploy the policy in your environment.
+This article assumes you're using a test machine so that you can test PowerShell behavior under a
+machine wide WDAC policy before you deploy the policy in your environment.
 
 ## Create a WDAC policy
 
@@ -21,8 +21,8 @@ approved files are allowed to load and run. PowerShell either blocks unapproved
 running or runs them in `ConstrainedLanguage` mode, depending on policy options.
 
 You create and manipulate WDAC policy using the **ConfigCI** module, which is available on all
-supported Windows versions. This Windows PowerShell module can be used in Windows PowerShell 5.1
-or in PowerShell 7 through the **Windows Compatibility** layer. It's easier to use this module in
+supported Windows versions. This Windows PowerShell module can be used in Windows PowerShell 5.1 or
+in PowerShell 7 through the **Windows Compatibility** layer. It's easier to use this module in
 Windows PowerShell. The policy you create can be applied to any version of PowerShell.
 
 ## Steps to create a WDAC policy
@@ -44,8 +44,8 @@ For testing, you just need to create a default policy and a self signed code sig
 1. Disable Audit Mode in default policy
 
    A new policy is always created in `Audit` mode. To test policy enforcement, you need to disable
-   Audit mode when you apply the policy. Edit the `SystemCIPolicy.xml` file using a text editor
-   like `notepad.exe` or Visual Studio Code (VS Code). Comment out the `Audit mode` option.
+   Audit mode when you apply the policy. Edit the `SystemCIPolicy.xml` file using a text editor like
+   `notepad.exe` or Visual Studio Code (VS Code). Comment out the `Audit mode` option.
 
    ```XML
    <!--

reference/docs-conceptual/security/app-control/how-wdac-works.md

@@ -12,8 +12,7 @@ and PowerShell you're using.
 ## How PowerShell detects a system lockdown policy
 
 PowerShell detects both **AppLocker** and **Windows Defender Application Control** (WDAC) system
-wide polices. AppLocker is deprecated. WDAC is the preferred application control system for
-Windows.
+wide polices. AppLocker is deprecated. WDAC is the preferred application control system for Windows.
 
 ### Legacy WDAC policy enforcement detection
 
@@ -44,8 +43,8 @@ PowerShell can run in both interactive and non-interactive modes.
 
 - In interactive mode, PowerShell is a command-line application that takes users command-line input
   as commands or scripts to run. Results are displayed back to the user.
-- In non-interactive mode, PowerShell loads modules and runs script files without user
-  input. Result data streams are either ignored or redirected to a file.
+- In non-interactive mode, PowerShell loads modules and runs script files without user input. Result
+  data streams are either ignored or redirected to a file.
 
 ### Interactive mode running under policy enforcement
 
@@ -61,8 +60,8 @@ for the file.
 PowerShell version 7.3 or higher uses the `WldpCanExecuteFile` API if available. This API returns one
 of the following results:
 
-- `WLDP_CAN_EXECUTE_ALLOWED`: The file is approved by policy and is used in `FullLanguage` mode
-  with a few restrictions.
+- `WLDP_CAN_EXECUTE_ALLOWED`: The file is approved by policy and is used in `FullLanguage` mode with
+  a few restrictions.
 - `WLDP_CAN_EXECUTE_BLOCKED`: The file isn't approved by policy. PowerShell throws an error when the
   file is run or loaded.
 - `WLDP_CAN_EXECUTE_REQUIRE_SANDBOX`: The file isn't approved by the policy but it can still be run
@@ -78,26 +77,27 @@ behavior is:
 
 ## PowerShell restrictions under lockdown policy
 
-When PowerShell detects the system is under a WDAC lockdown policy, it applies restrictions
-even if the script is trusted and running in `FullLanguage` mode. These restrictions prevent known
-behaviors of PowerShell that could result in arbitrary code execution on a locked-down system. The
-lockdown policy enforces the following restrictions:
+When PowerShell detects the system is under a WDAC lockdown policy, it applies restrictions even if
+the script is trusted and running in `FullLanguage` mode. These restrictions prevent known behaviors
+of PowerShell that could result in arbitrary code execution on a locked-down system. The lockdown
+policy enforces the following restrictions:
 
 - Module dot-sourcing with wildcard function export restriction
 
-  Any module that uses script dot-sourcing and exports functions using wildcard names results
-  in an error. Blocking wildcard exports prevents script injection from a malicious user who can
-  plant an untrusted script that gets dot-sourced into a trusted module. The malicious script could then gain access to the trusted module's private functions.
+  Any module that uses script dot-sourcing and exports functions using wildcard names results in an
+  error. Blocking wildcard exports prevents script injection from a malicious user who can plant an
+  untrusted script that gets dot-sourced into a trusted module. The malicious script could then gain
+  access to the trusted module's private functions.
 
   **Security recommendation:** Never use script dot-sourcing in a module and always export module
   functions with explicit names (no wildcard characters).
 
 - Nested module with wildcard function export restriction
 
-  If a parent module exports functions using function name wildcard characters, PowerShell
-  removes any function name in a nested module from the function export list. Blocking wildcard exports
-  from nested modules prevents accidental exporting of dangerous nested functions through wildcard
-  name matching.
+  If a parent module exports functions using function name wildcard characters, PowerShell removes
+  any function name in a nested module from the function export list. Blocking wildcard exports from
+  nested modules prevents accidental exporting of dangerous nested functions through wildcard name
+  matching.
 
   **Security recommendation:** Always export module functions with explicit names (no wildcard
   characters).
@@ -223,8 +223,8 @@ command, PowerShell either blocks the command from running (new behavior) or run
 
 - Type method invocation not allowed
 
-  `ConstrainedLanguage` mode doesn't allow method invocation on unapproved types. Blocking methods on
-  unapproved types prevents invocation of .NET type methods that might be dangerous or allow code
+  `ConstrainedLanguage` mode doesn't allow method invocation on unapproved types. Blocking methods
+  on unapproved types prevents invocation of .NET type methods that might be dangerous or allow code
   injection.
 
 - Type property setters not allowed

reference/docs-conceptual/security/security-features.md

@@ -49,8 +49,8 @@ For more information, see the following articles:
 ## AMSI Support
 
 The Windows Antimalware Scan Interface (AMSI) is an API that allows applications to pass actions to
-an antimalware scanner, such as Windows Defender, to scan for malicious payloads. Beginning
-with PowerShell 5.1, PowerShell running on Windows 10 (and higher) passes all script blocks to AMSI.
+an antimalware scanner, such as Windows Defender, to scan for malicious payloads. Beginning with
+PowerShell 5.1, PowerShell running on Windows 10 (and higher) passes all script blocks to AMSI.
 
 PowerShell 7.3 extends the data that's sent to AMSI for inspection. It now includes all invocations
 of .NET method members.
@@ -59,8 +59,8 @@ For more information about AMSI, see [How AMSI helps][09].
 
 ## Constrained language mode
 
-**ConstrainedLanguage** mode protects your system by limiting the cmdlets and .NET types
-allowed in a PowerShell session. For a full description, see [about_Language_Modes][04].
+**ConstrainedLanguage** mode protects your system by limiting the cmdlets and .NET types allowed in
+a PowerShell session. For a full description, see [about_Language_Modes][04].
 
 ## Application Control
 
@@ -88,8 +88,8 @@ You can find SBOM files in the following locations:
 - For modules, find the SBOM in the module's folder under `_manifest/spdx_2.2/manifest.spdx.json`.
 
 The creation and publishing of the SBOM is the first step to modernize Federal Government
-cybersecurity and enhance software supply chain security. For more information about this initiative,
-see the blog post [Generating Software Bills of Materials (SBOMs) with SPDX at Microsoft][11].
+cybersecurity and enhance software supply chain security. For more information about this
+initiative, see the blog post [Generating SBOMs with SPDX at Microsoft][11].
 
 ## Security Servicing Criteria