Skip to content

Commit f4af2ee

Browse files
Apply suggestions from code review
Co-authored-by: Mike F. Robbins <[email protected]>
1 parent 463a71e commit f4af2ee

File tree

4 files changed

+26
-28
lines changed

4 files changed

+26
-28
lines changed

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

Lines changed: 7 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ based on unique properties of the files.
1616
**WDAC**, introduced with Windows 10, allows you to control which drivers and applications are
1717
allowed to run on Windows.
1818

19-
PowerShell detects both AppLocker and WDAC system wide policies. AppLocker is a deprecated. WDAC is
19+
PowerShell detects both AppLocker and WDAC system wide policies. AppLocker is deprecated. WDAC is
2020
the preferred application control system for Windows. WDAC is designed as a security feature under
2121
the servicing criteria defined by the Microsoft Security Response Center (MSRC).
2222

@@ -31,7 +31,7 @@ For more information about AppLocker and WDAC, see [Application Controls for Win
3131
3232
## WDAC policy enforcement
3333

34-
When PowerShell runs under a WDAC policy, it changes its behavior based on the defined security
34+
When PowerShell runs under a WDAC policy, its behavior changes based on the defined security
3535
policy. Under a WDAC policy, PowerShell runs trusted scripts and modules allowed by the policy in
3636
`FullLanguage` mode. All other scripts and script blocks are untrusted and run in
3737
`ConstrainedLanguage` mode. PowerShell throws errors when the untrusted scripts attempt to perform
@@ -42,28 +42,27 @@ failed to run correctly in `ConstrainedLanguage` mode.
4242

4343
PowerShell 7.4 added a new feature to support WDAC policies in **Audit** mode. In audit mode,
4444
PowerShell runs the untrusted scripts in `ConstrainedLanguage` mode without errors, but logs messages
45-
to the event log instead. The log messages describe what restrictions would apply if the policy was
45+
to the event log instead. The log messages describe what restrictions would apply if the policy were
4646
in **Enforce** mode.
4747

4848
## History of changes
4949

5050
Windows PowerShell 5.1 was the first version of PowerShell to support WDAC. The security features of
5151
WDAC and AppLocker improve with each new release of PowerShell. The following sections describe how
5252
this support changed in each version of PowerShell. The changes are cumulative, so the features
53-
described in the later versions include the features from the earlier versions.
53+
described in the later versions include those from earlier versions.
5454

5555
### Changes in PowerShell 7.4
5656

57-
On Windows, when PowerShell runs under a Windows Defender Application Control (WDAC) policy, it
58-
changes its behavior based on the defined security policy. Under a WDAC policy, PowerShell runs
57+
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
5958
trusted scripts and modules allowed by the policy in `FullLanguage` mode. All other scripts and
6059
script blocks are untrusted and run in `ConstrainedLanguage` mode. PowerShell throws errors when the
6160
untrusted scripts attempt to perform disallowed actions. It's difficult to know why a script fails
6261
to run correctly in `ConstrainedLanguage` mode.
6362

6463
PowerShell 7.4 now supports WDAC policies in **Audit** mode. In audit mode, PowerShell runs the
6564
untrusted scripts in `ConstrainedLanguage` mode but logs messages to the event log instead of
66-
throwing errors. The log messages describe what restrictions would apply if the policy was in
65+
throwing errors. The log messages describe what restrictions would apply if the policy were in
6766
**Enforce** mode.
6867

6968
### Changes in PowerShell 7.3
@@ -87,7 +86,7 @@ throwing errors. The log messages describe what restrictions would apply if the
8786

8887
- For more information about how WDAC works and what restrictions it enforces, see
8988
[How WDAC works with PowerShell][06].
90-
- For more information about using securing PowerShell with WDAC, see [How to use WDAC][05].
89+
- For more information about securing PowerShell with WDAC, see [How to use WDAC][05].
9190

9291
<!-- link references -->
9392
[01]: /windows/security/threat-protection/windows-defender-application-control/applocker/what-is-applocker

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

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@ approved files are allowed to load and run. PowerShell either blocks unapproved
2121
running or runs them in `ConstrainedLanguage` mode, depending on policy options.
2222

2323
You create and manipulate WDAC policy using the **ConfigCI** module, which is available on all
24-
supported Windows version. This Windows PowerShell module that can be used in Windows PowerShell 5.1
24+
supported Windows versions. This Windows PowerShell module can be used in Windows PowerShell 5.1
2525
or in PowerShell 7 through the **Windows Compatibility** layer. It's easier to use this module in
2626
Windows PowerShell. The policy you create can be applied to any version of PowerShell.
2727

@@ -44,7 +44,7 @@ For testing, you just need to create a default policy and a self signed code sig
4444
1. Disable Audit Mode in default policy
4545

4646
A new policy is always created in `Audit` mode. To test policy enforcement, you need to disable
47-
Audit mode when you apply the the policy. Edit the `SystemCIPolicy.xml` file using text editor
47+
Audit mode when you apply the policy. Edit the `SystemCIPolicy.xml` file using a text editor
4848
like `notepad.exe` or Visual Studio Code (VS Code). Comment out the `Audit mode` option.
4949

5050
```XML
@@ -115,7 +115,7 @@ For testing, you just need to create a default policy and a self signed code sig
115115
PowerShell 7.4 added a new feature to support WDAC policies in **Audit** mode. In audit mode,
116116
PowerShell runs the untrusted scripts in `ConstrainedLanguage` mode without errors, but logs
117117
messages to the event log instead. The log messages describe what restrictions would apply if the
118-
policy was in **Enforce** mode.
118+
policy were in **Enforce** mode.
119119

120120
### Viewing audit events
121121

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

Lines changed: 12 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -44,21 +44,21 @@ PowerShell can run in both interactive and non-interactive modes.
4444

4545
- In interactive mode, PowerShell is a command-line application that takes users command-line input
4646
as commands or scripts to run. Results are displayed back to the user.
47-
- In non-interactive mode, PowerShell is used to load modules and run script files without user
48-
input. Result data streams are either ignored or redirected to file.
47+
- In non-interactive mode, PowerShell loads modules and runs script files without user
48+
input. Result data streams are either ignored or redirected to a file.
4949

5050
### Interactive mode running under policy enforcement
5151

5252
PowerShell runs commands in `ConstrainedLanguage` mode. This mode prevents interactive users from
5353
running certain commands or executing arbitrary code. For more information about the restrictions in
54-
this mode, see the [PowerShell restrictions under lockdown policy][02] of this article.
54+
this mode, see the [PowerShell restrictions under lockdown policy][02] section of this article.
5555

5656
### Noninteractive mode running under policy enforcement
5757

5858
When PowerShell runs a script or loads a module, it uses the WDAC API to get the policy enforcement
5959
for the file.
6060

61-
PowerShell version 7.3 or higher uses the `WldpCanExecuteFile` API if available. This API return one
61+
PowerShell version 7.3 or higher uses the `WldpCanExecuteFile` API if available. This API returns one
6262
of the following results:
6363

6464
- `WLDP_CAN_EXECUTE_ALLOWED`: The file is approved by policy and is used in `FullLanguage` mode
@@ -85,19 +85,18 @@ lockdown policy enforces the following restrictions:
8585

8686
- Module dot-sourcing with wildcard function export restriction
8787

88-
Any module that uses script dot-sourcing and also exports functions using wildcard names results
88+
Any module that uses script dot-sourcing and exports functions using wildcard names results
8989
in an error. Blocking wildcard exports prevents script injection from a malicious user who can
90-
plant an untrusted script that gets dot-sourced into a trusted module. The malicious script could
91-
get access to private functions of the trusted module.
90+
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.
9291

93-
**Security recommendation:** Never use script dot-sourcing in a module and to always export module
92+
**Security recommendation:** Never use script dot-sourcing in a module and always export module
9493
functions with explicit names (no wildcard characters).
9594

9695
- Nested module with wildcard function export restriction
9796

98-
If a parent module exports functions using function name wildcard characters, then PowerShell
99-
removes any function name in a nested module from the function export list. Block wildcard exports
100-
from nested modules prevents accidental exporting of dangerous nested functions through wildcards
97+
If a parent module exports functions using function name wildcard characters, PowerShell
98+
removes any function name in a nested module from the function export list. Blocking wildcard exports
99+
from nested modules prevents accidental exporting of dangerous nested functions through wildcard
101100
name matching.
102101

103102
**Security recommendation:** Always export module functions with explicit names (no wildcard
@@ -135,7 +134,7 @@ command, PowerShell either blocks the command from running (new behavior) or run
135134

136135
- `Add-Type` cmdlet disallowed
137136

138-
Blocking `Add-Type` prevents the execution arbitrary .NET code.
137+
Blocking `Add-Type` prevents the execution of arbitrary .NET code.
139138

140139
- `Import-LocalizedData` cmdlet restricted
141140

@@ -224,7 +223,7 @@ command, PowerShell either blocks the command from running (new behavior) or run
224223

225224
- Type method invocation not allowed
226225

227-
`ConstrainedLanguage` mode doesn't allow method invocation on unapproved types. Blocking method on
226+
`ConstrainedLanguage` mode doesn't allow method invocation on unapproved types. Blocking methods on
228227
unapproved types prevents invocation of .NET type methods that might be dangerous or allow code
229228
injection.
230229

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

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -48,7 +48,7 @@ For more information, see the following articles:
4848

4949
## AMSI Support
5050

51-
The Windows Antimalware Scan Interface (AMSI) is an API that allows application to pass actions to
51+
The Windows Antimalware Scan Interface (AMSI) is an API that allows applications to pass actions to
5252
an antimalware scanner, such as Windows Defender, to scan for malicious payloads. Beginning
5353
with PowerShell 5.1, PowerShell running on Windows 10 (and higher) passes all script blocks to AMSI.
5454

@@ -59,7 +59,7 @@ For more information about AMSI, see [How AMSI helps][09].
5959

6060
## Constrained language mode
6161

62-
**ConstrainedLanguage** mode protects your system by limiting the cmdlets and .NET types that are
62+
**ConstrainedLanguage** mode protects your system by limiting the cmdlets and .NET types
6363
allowed in a PowerShell session. For a full description, see [about_Language_Modes][04].
6464

6565
## Application Control
@@ -79,7 +79,7 @@ For more information about how PowerShell supports AppLocker and WDAC, see
7979
## Software Bill of Materials (SBOM)
8080

8181
Beginning with PowerShell 7.2, all install packages contain a Software Bill of Materials (SBOM). The
82-
PowerShell team is also producing SBOMs for modules that they own but ship independently from
82+
PowerShell team also produces SBOMs for modules that they own but ship independently from
8383
PowerShell.
8484

8585
You can find SBOM files in the following locations:
@@ -88,7 +88,7 @@ You can find SBOM files in the following locations:
8888
- For modules, find the SBOM in the module's folder under `_manifest/spdx_2.2/manifest.spdx.json`.
8989

9090
The creation and publishing of the SBOM is the first step to modernize Federal Government
91-
cybersecurity and enhance software supply chain security.For more information about this initiative,
91+
cybersecurity and enhance software supply chain security. For more information about this initiative,
9292
see the blog post [Generating Software Bills of Materials (SBOMs) with SPDX at Microsoft][11].
9393

9494
## Security Servicing Criteria

0 commit comments

Comments
 (0)