From 088f5af22cc286261dadccc144dcde8c0604ae2f Mon Sep 17 00:00:00 2001 From: Sean Wheeler Date: Thu, 19 Sep 2024 20:35:35 -0500 Subject: [PATCH 1/5] Reorg security docs and add more WDAC content --- .../docs-conceptual/security/app-control/how-to-use-wdac.md | 4 ++++ reference/docs-conceptual/security/overview.yml | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/reference/docs-conceptual/security/app-control/how-to-use-wdac.md b/reference/docs-conceptual/security/app-control/how-to-use-wdac.md index 482139c24fb9..775fc4b9bf6e 100644 --- a/reference/docs-conceptual/security/app-control/how-to-use-wdac.md +++ b/reference/docs-conceptual/security/app-control/how-to-use-wdac.md @@ -44,7 +44,11 @@ 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 +<<<<<<< HEAD Audit mode when you apply the policy. Edit the `SystemCIPolicy.xml` file using a text editor +======= + Audit mode when you apply the the policy. Edit the `SystemCIPolicy.xml` file using text editor +>>>>>>> 0c467cf87 (Reorg security docs and add more WDAC content) like `notepad.exe` or Visual Studio Code (VS Code). Comment out the `Audit mode` option. ```XML diff --git a/reference/docs-conceptual/security/overview.yml b/reference/docs-conceptual/security/overview.yml index 6aeb39700a7e..43794bc3710d 100644 --- a/reference/docs-conceptual/security/overview.yml +++ b/reference/docs-conceptual/security/overview.yml @@ -85,7 +85,11 @@ landingContent: - linkListType: how-to-guide links: - text: How to use WDAC to secure PowerShell +<<<<<<< HEAD url: app-control/how-to-use-wdac.md +======= + url: security/app-control/how-to-use-wdac.md +>>>>>>> 0c467cf87 (Reorg security docs and add more WDAC content) # Card - title: Managing secrets From 11407d5c9d35023d7a0d36dc61729480a3ee33cf Mon Sep 17 00:00:00 2001 From: Sean Wheeler Date: Thu, 19 Sep 2024 20:55:00 -0500 Subject: [PATCH 2/5] fix broken links --- reference/docs-conceptual/security/overview.yml | 4 ---- 1 file changed, 4 deletions(-) diff --git a/reference/docs-conceptual/security/overview.yml b/reference/docs-conceptual/security/overview.yml index 43794bc3710d..6aeb39700a7e 100644 --- a/reference/docs-conceptual/security/overview.yml +++ b/reference/docs-conceptual/security/overview.yml @@ -85,11 +85,7 @@ landingContent: - linkListType: how-to-guide links: - text: How to use WDAC to secure PowerShell -<<<<<<< HEAD url: app-control/how-to-use-wdac.md -======= - url: security/app-control/how-to-use-wdac.md ->>>>>>> 0c467cf87 (Reorg security docs and add more WDAC content) # Card - title: Managing secrets From 1b5e35f6f95a25d7d132fabe0d5f240821e0b48d Mon Sep 17 00:00:00 2001 From: Sean Wheeler Date: Tue, 24 Sep 2024 07:53:58 -0500 Subject: [PATCH 3/5] Fix statement about logic of ConfirmImpact --- .../cmdlet/users-requesting-confirmation.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/reference/docs-conceptual/developer/cmdlet/users-requesting-confirmation.md b/reference/docs-conceptual/developer/cmdlet/users-requesting-confirmation.md index 4abb19bec940..85a46cd5e3d0 100644 --- a/reference/docs-conceptual/developer/cmdlet/users-requesting-confirmation.md +++ b/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,15 +9,14 @@ 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. @@ -25,7 +24,7 @@ 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 From 6494d26f9c1d7490790ddd5f2b5d11372c2d0368 Mon Sep 17 00:00:00 2001 From: Sean Wheeler Date: Tue, 24 Sep 2024 08:04:27 -0500 Subject: [PATCH 4/5] Fix merge conflict --- .../docs-conceptual/security/app-control/how-to-use-wdac.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/reference/docs-conceptual/security/app-control/how-to-use-wdac.md b/reference/docs-conceptual/security/app-control/how-to-use-wdac.md index 775fc4b9bf6e..482139c24fb9 100644 --- a/reference/docs-conceptual/security/app-control/how-to-use-wdac.md +++ b/reference/docs-conceptual/security/app-control/how-to-use-wdac.md @@ -44,11 +44,7 @@ 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 -<<<<<<< HEAD Audit mode when you apply the policy. Edit the `SystemCIPolicy.xml` file using a text editor -======= - Audit mode when you apply the the policy. Edit the `SystemCIPolicy.xml` file using text editor ->>>>>>> 0c467cf87 (Reorg security docs and add more WDAC content) like `notepad.exe` or Visual Studio Code (VS Code). Comment out the `Audit mode` option. ```XML From 576cd92886f6c8a4f7f801d5bf424dd341cf1e18 Mon Sep 17 00:00:00 2001 From: Sean Wheeler Date: Tue, 24 Sep 2024 08:08:39 -0500 Subject: [PATCH 5/5] Reflow --- .../app-control/application-control.md | 20 +++++----- .../security/app-control/how-to-use-wdac.md | 12 +++--- .../security/app-control/how-wdac-works.md | 38 +++++++++---------- .../security/security-features.md | 12 +++--- 4 files changed, 42 insertions(+), 40 deletions(-) diff --git a/reference/docs-conceptual/security/app-control/application-control.md b/reference/docs-conceptual/security/app-control/application-control.md index 56b473edf6f3..b784de2e52c5 100644 --- a/reference/docs-conceptual/security/app-control/application-control.md +++ b/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 diff --git a/reference/docs-conceptual/security/app-control/how-to-use-wdac.md b/reference/docs-conceptual/security/app-control/how-to-use-wdac.md index 482139c24fb9..0e58f08e75e7 100644 --- a/reference/docs-conceptual/security/app-control/how-to-use-wdac.md +++ b/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