PowerShell security features
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/PowerShell-Docs · commit d2da3d7 · +129 −0 lines · also on GitHub
The file is new at this commit, or was moved here from another path: every line shows as added.
1
+---
2
+description: PowerShell has several features designed to improve the security of your scripting environment.
3
+ms.date: 09/29/2023
4
+title: PowerShell security features
5
+---
6
+# PowerShell security features
7
+
8
+PowerShell has several features designed to improve the security of your scripting environment.
9
+
10
+## Execution policy
11
+
12
+PowerShell's execution policy is a safety feature that controls the conditions under which
13
+PowerShell loads configuration files and runs scripts. This feature helps prevent the execution of
14
+malicious scripts. You can use a Group Policy setting to set execution policies for computers and
15
+users. Execution policies only apply to the Windows platform.
16
+
17
+For more information see [about_Execution_Policies][02].
18
+
19
+## Module and script block logging
20
+
21
+Module Logging allows you to enable logging for selected PowerShell modules. This setting is
22
+effective in all sessions on the computer. Pipeline execution events for the specified modules are
23
+recorded in the Windows PowerShell log in Event Viewer.
24
+
25
+Script Block Logging enables logging for the processing of commands, script blocks, functions, and
26
+scripts - whether invoked interactively, or through automation. This information is logged to the
27
+**Microsoft-Windows-PowerShell/Operational** event log.
28
+
29
+For more information, see the following articles:
30
+
31
+- [about_Group_Policy_Settings][03]
32
+- [about_Logging_Windows][06]
33
+- [about_Logging_Non-Windows][05]
34
+
35
+## AMSI Support
36
+
37
+The Windows Antimalware Scan Interface (AMSI) is an API that allows application actions to be passed
38
+to an antimalware scanner, such as Windows Defender, to be scanned for malicious payloads. Beginning
39
+with PowerShell 5.1, PowerShell running on Windows 10 (and higher) passes all script blocks to AMSI.
40
+
41
+PowerShell 7.3 extends the data that's sent to AMSI for inspection. It now includes all invocations
42
+of .NET method members.
43
+
44
+For more information about AMSI, see [How AMSI helps][11].
45
+
46
+## Constrained language mode
47
+
48
+**ConstrainedLanguage** mode protects your system by limiting the cmdlets and .NET types that can be
49
+used in a PowerShell session. For a full description, see [about_Language_Modes][04].
50
+
51
+## Application Control
52
+
53
+Windows 10 includes two technologies, [Windows Defender Application Control (WDAC)][10] and
54
+[AppLocker][07] that you can use to control applications. They allow you to create a lockdown
55
+experience to help secure your PowerShell environment.
56
+
57
+For more information about how PowerShell supports AppLocker and WDAC, see
58
+[Using Windows Defender Application Control][01].
59
+
60
+### Changes in PowerShell 7.4
61
+
62
+On Windows, when PowerShell runs under a Windows Defender Application Control (WDAC) policy, it
63
+changes its behavior based on the defined security policy. Under a WDAC policy, PowerShell runs
64
+trusted scripts and modules allowed by the policy in Full Language mode. All other scripts and
65
+script blocks are untrusted and run in Constrained Language mode. PowerShell throws errors when the
66
+untrusted scripts attempt to perform disallowed actions. It's difficult to know why a script fails
67
+to run correctly in Constrained Language mode.
68
+
69
+PowerShell 7.4 now supports WDAC policies in **Audit** mode. In audit mode, PowerShell runs the
70
+untrusted scripts in Constrained Language mode but logs messages to the event log instead of
71
+throwing errors. The log messages describe what restrictions would apply if the policy was in
72
+**Enforce** mode.
73
+
74
+### Changes in PowerShell 7.3
75
+
76
+- PowerShell 7.3 now supports the ability to block or allow PowerShell script files via the WDAC API.
77
+
78
+### Changes in PowerShell 7.2
79
+
80
+- There was a corner-case scenario in AppLocker where you only have **Deny** rules and constrained
81
+ mode isn't used to enforce the policy that allows you to bypass the execution policy. Beginning in
82
+ PowerShell 7.2, a change was made to ensure AppLocker rules take precedence over a
83
+ `Set-ExecutionPolicy -ExecutionPolicy Bypass` command.
84
+
85
+- PowerShell 7.2 now disallows the use of the `Add-Type` cmdlet in a **NoLanguage** mode PowerShell
86
+ session on a locked down machine.
87
+
88
+- PowerShell 7.2 now disallows scripts from using COM objects in AppLocker system lock down
89
+ conditions. Cmdlet that use COM or DCOM internally aren't affected.
90
+
91
+### Security Servicing Criteria
92
+
93
+PowerShell follows the [Microsoft Security Servicing Criteria for Windows][13]. The table below
94
+outlines the features that meet the servicing criteria and those that do not.
95
+
96
+| Feature | Type |
97
+| ------------------------------------------ | ---------------- |
98
+| System Lockdown - with WDAC | Security Feature |
99
+| Constrained language mode - with WDAC | Security Feature |
100
+| System Lockdown - with AppLocker | Defense in Depth |
101
+| Constrained language mode - with AppLocker | Defense in Depth |
102
+| Execution Policy | Defense in Depth |
103
+
104
+## Software Bill of Materials (SBOM)
105
+
106
+Beginning with PowerShell 7.2, all install packages contain a Software Bill of Materials (SBOM). The
107
+SBOM is found at `$PSHOME/_manifest/spdx_2.2/manifest.spdx.json`. The creation and publishing of the
108
+SBOM is the first step to modernize Federal Government cybersecurity and enhance software supply
109
+chain security.
110
+
111
+The PowerShell team is also producing SBOMs for modules that they own but ship separately from
112
+PowerShell. SBOMs will be added in the next release of the module. For modules, the SBOM is
113
+installed in the module's folder under `_manifest/spdx_2.2/manifest.spdx.json`.
114
+
115
+For more information about this initiative, see the blog post
116
+[Generating Software Bills of Materials (SBOMs) with SPDX at Microsoft][12].
117
+
118
+<!-- link references -->
119
+[01]: ./application-control.md
120
+[02]: /powershell/module/microsoft.powershell.core/about/about_execution_policies
121
+[03]: /powershell/module/microsoft.powershell.core/about/about_group_policy_settings#turn-on-module-logging
122
+[04]: /powershell/module/microsoft.powershell.core/about/about_language_modes
123
+[05]: /powershell/module/microsoft.powershell.core/about/about_logging_non-windows
124
+[06]: /powershell/module/microsoft.powershell.core/about/about_logging_windows
125
+[07]: /windows/security/threat-protection/windows-defender-application-control/applocker/what-is-applocker
126
+[10]: /windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control
127
+[11]: /windows/win32/amsi/how-amsi-helps
128
+[12]: https://devblogs.microsoft.com/engineering-at-microsoft/generating-software-bills-of-materials-sboms-with-spdx-at-microsoft/
129
+[13]: https://www.microsoft.com/msrc/windows-security-servicing-criteria
Microsoft's Markdown source from MicrosoftDocs/PowerShell-Docs, © Microsoft Corporation, under CC BY 4.0. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 18:27 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.