Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

7/8/2024 PM Publish #11241

Merged
merged 2 commits into from
Jul 8, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 26 additions & 11 deletions reference/docs-conceptual/security/security-features.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
description: PowerShell has several features designed to improve the security of your scripting environment.
ms.date: 09/29/2023
ms.date: 07/08/2024
title: PowerShell security features
---
# PowerShell security features
Expand All @@ -16,6 +16,20 @@ users. Execution policies only apply to the Windows platform.

For more information see [about_Execution_Policies][02].

## Use of the SecureString class

PowerShell has several cmdlets that support the use of the `System.Security.SecureString` class.
And, as with any .NET class, you can use **SecureString** in your own scripts. However, Microsoft
doesn't recommend using **SecureString** for new development. Microsoft recommends that you avoid
using passwords and rely on other means to authenticate, such as certificates or Windows
authentication.

PowerShell continues to support the **SecureString** class for backward compatibility. Using a
**SecureString** is still more secure than using a plain text string. By default, PowerShell doesn't
show the unprotected value of a **SecureString** object. However, **SecureString** can be easily
converted to a plain text string. For a full discussion about using **SecureString**, see the
[System.Security.SecureString class][01] documentation.

## Module and script block logging

Module Logging allows you to enable logging for selected PowerShell modules. This setting is
Expand All @@ -41,7 +55,7 @@ with PowerShell 5.1, PowerShell running on Windows 10 (and higher) passes all sc
PowerShell 7.3 extends the data that's sent to AMSI for inspection. It now includes all invocations
of .NET method members.

For more information about AMSI, see [How AMSI helps][11].
For more information about AMSI, see [How AMSI helps][09].

## Constrained language mode

Expand All @@ -50,12 +64,12 @@ used in a PowerShell session. For a full description, see [about_Language_Modes]

## Application Control

Windows 10 includes two technologies, [Windows Defender Application Control (WDAC)][10] and
Windows 10 includes two technologies, [Windows Defender Application Control (WDAC)][08] and
[AppLocker][07] that you can use to control applications. They allow you to create a lockdown
experience to help secure your PowerShell environment.

For more information about how PowerShell supports AppLocker and WDAC, see
[Using Windows Defender Application Control][01].
[Using Windows Defender Application Control][10].

### Changes in PowerShell 7.4

Expand Down Expand Up @@ -90,7 +104,7 @@ throwing errors. The log messages describe what restrictions would apply if the

### Security Servicing Criteria

PowerShell follows the [Microsoft Security Servicing Criteria for Windows][13]. The table below
PowerShell follows the [Microsoft Security Servicing Criteria for Windows][12]. The table below
outlines the features that meet the servicing criteria and those that do not.

| Feature | Type |
Expand All @@ -113,17 +127,18 @@ PowerShell. SBOMs will be added in the next release of the module. For modules,
installed in the module's folder under `_manifest/spdx_2.2/manifest.spdx.json`.

For more information about this initiative, see the blog post
[Generating Software Bills of Materials (SBOMs) with SPDX at Microsoft][12].
[Generating Software Bills of Materials (SBOMs) with SPDX at Microsoft][11].

<!-- link references -->
[01]: ./application-control.md
[01]: /dotnet/fundamentals/runtime-libraries/system-security-securestring
[02]: /powershell/module/microsoft.powershell.core/about/about_execution_policies
[03]: /powershell/module/microsoft.powershell.core/about/about_group_policy_settings#turn-on-module-logging
[04]: /powershell/module/microsoft.powershell.core/about/about_language_modes
[05]: /powershell/module/microsoft.powershell.core/about/about_logging_non-windows
[06]: /powershell/module/microsoft.powershell.core/about/about_logging_windows
[07]: /windows/security/threat-protection/windows-defender-application-control/applocker/what-is-applocker
[10]: /windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control
[11]: /windows/win32/amsi/how-amsi-helps
[12]: https://devblogs.microsoft.com/engineering-at-microsoft/generating-software-bills-of-materials-sboms-with-spdx-at-microsoft/
[13]: https://www.microsoft.com/msrc/windows-security-servicing-criteria
[08]: /windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control
[09]: /windows/win32/amsi/how-amsi-helps
[10]: application-control.md
[11]: https://devblogs.microsoft.com/engineering-at-microsoft/generating-software-bills-of-materials-sboms-with-spdx-at-microsoft/
[12]: https://www.microsoft.com/msrc/windows-security-servicing-criteria
Loading