Harden Windows Security module v0.2.8 #177
Conversation
|
@agpt8 After checking the code I think we're already using the latest version which is 2306.
This page doesn't give me any newer version https://www.microsoft.com/en-us/download/details.aspx?id=55319 The tech community post mentions "Microsoft 365 Apps for enterprise version 2312" but looks like it's just a refresh of 2306. They do need to update the docs though |
|
What about the excel sheet that they have attached in that post? Can we manually apply those, if not already applied by the script? It's so weird that they haven't updated the docs or the download page. |
|
I made some comments under the tech community post, hopefully they will reply soon, the changes in v5423 aren't in the available zip package...I checked the excel sheet included in the package and it didn't have those new policies. It shouldn't be hard to create a GPO based on those 4 new items though |
for the new category
This has 3 main benefits, 1) offers granular control sub-category automation 2) handles the parameter validation and correlation between selected categories and the subcategory switch parameter 3) Doesn't populate the argument completer on the console with unrelated parameter. Not complete yet, more to come soon for the rest of the sub-categories.
Harden-Windows-Security Module/Main files/Core/Protect-WindowsSecurity.psm1
Outdated
Show resolved
Hide resolved
Thanks @agpt8 for catching it Co-Authored-By: Ayush Gupta <[email protected]>
The huge code change is due to implementing Begin and process blocks around the entire code and shifting the indentations. All of the dynamic parameters are now properly implemented to support changing the sub-categories' automation.
Added: Verify the 3 built-in Firewall rules (for all 3 profiles) for Multicast DNS (mDNS) UDP-in are disabled
Since there is no longer a payload folder in the root of the repository, the workflow must be checking the resources folder for files to send to VT for scan
What's Changed
Complete Redesign
Revamped the architecture of the Harden Windows Security script. The new versatile design enables a single file to function as an independent script and as a component of the Harden Windows Security module, at the same time.
The All New Hybrid Mode of Operation
The Harden Windows Security module now supports headless or silent mode of operation. This mode enables you to run the module without any interaction on the PowerShell console. You simply choose the categories you wish to apply automatically, and the module will perform them for you. If a selected category requires Administrator privileges and the module is running with Standard privileges, that category is skipped.
Facilitating Large-Scale Deployments
This modification, in conjunction with other improvements in this version, prepare the Harden Windows Security module for deployments at a large scale.
Available Parameters for Protect-WindowsSecurity Cmdlet
The following parameters are only for the headless/silent mode of operation.
-Categories: Optional; Specify the hardening categories that you want to apply. This will tell the module to operate in non-interactive or headless/silent mode which won't ask for confirmation before running each selected categories. You can specify multiple categories by separating them with a comma. If you don't specify any category, the cmdlet will run in interactive mode. Use this parameter for deployments at a large scale. If a selected category requires Administrator privileges and the module is running with Standard privileges, that category is skipped.Tabkey to see the available categories.-Verbose: Optional; Shows verbose messages on the console about what the cmdlet is doing.Note
You can further control the sub-categories of each category by using the following switch parameters. Pay attention to the naming convention of them. They are named after the category they belong to. For example, the switch parameter
-MSFTDefender_SACbelongs to theMicrosoftDefendercategory. The switch parameters are dynamic and will only appear if you specify the corresponding category in the-Categoriesparameter. For example, if you don't specify theMicrosoftDefendercategory in the-Categoriesparameter, the switch parameters related to it won't appear. The following table shows the available switch parameters and their corresponding categories.What if You Don’t Configure the Sub-Categories?
If you do not specify any sub-categories using the switch parameters above, the following sub-category configuration will be applied when the corresponding category exists in the
-Categoriesparameter.Important
It is highly recommended to always include the Microsoft Security Baselines category and place it first as it forms the foundation of all subsequent categories.
Example 1
If you run the module like this without specifying any categories, the module will run in interactive mode and the usual beautiful prompts will be displayed to the user.
Protect-WindowsSecurityExample 2
If you run the module like this, the 2 categories will be executed automatically without requiring any user input. The results will be displayed on the console.
Example 3
This example will apply the Microsoft Defender category with the Smart App Control sub-category, without the need for user interaction, and will show verbose messages.
Example 4
This example will apply the Microsoft Security Baselines, BitLocker, User Account Control, Lock Screen and Downloads Defense Measures categories. It will also apply the "Only Elevate Signed and Validated Executables" sub-category of the User Account Control category, and the "Require CTRL + ALT + DEL on Lock Screen" sub-category of the Lock Screen category.
More Secure Than Ever
The previous design necessitated downloading the essential files from the GitHub repository regardless of the execution mode, either as a script or as a module's cmdlets. The current design optimizes this process by only fetching the vital payload files when the script is invoked from GitHub as follows:
By installing and utilizing the Harden Windows Security module via the
Protect-WindowsSecuritycommand, the essential files are pre-included in the module and thus eliminate the need for downloading them separately. This enhances the security level and offers more peace of mind to the users.No Support for The Legacy Windows PowerShell
The new code excludes support for the old Windows PowerShell version 5.1, the default version installed with Windows. It was impeding the advancement and innovation in the code due to lack of compatibility with new features. Consequently, the new code base is more concise than before (despite offering more functionalities), more intelligent and more legible.
It is extremely easy to install the new modern PowerShell. The safest, fastest and best way to do so is through 🛍️ Microsoft Store.
By default, Windows Store packages run in an application sandbox that virtualizes access to some filesystem and registry locations. Changes to virtualized file and registry locations don't persist outside of the application sandbox.
This sandbox blocks all changes to the application's root folder. Any system-level configuration settings stored in $PSHOME can't be modified.
Alternatively, you can install PowerShell using Winget
PowerShell is modern and leverages the most recent .NET version and features. It is widely adopted in business and enterprise environments, and it eliminates the need and the rationale for relying on the archaic and old Windows PowerShell.
Downloads Defense Measures
To combat the threat of more sophisticated malware, a preemptive measure is taken by creating and deploying a WDAC policy on the system. This policy blocks the execution of executables and other potentially harmful file types in the Downloads folder, using the WDACConfig module.
This policy defends the system from malware that can launch itself automatically after being downloaded from the Internet. The user must ensure the file's safety and explicitly transfer it to a different folder before running it.
The WDAC policy employs a wildcard pattern to prevent any file from running in the Downloads folder. Additionally, it verifies that the system downloads folder in the user directory matches the downloads folder in the Edge browser's settings. If there is a discrepancy, a warning message is displayed on the console.
The policy can be removed by the Unprotect-WindowsSecurity or Remove-WDACConfig cmdlets.
It is an ongoing process so expect more WDAC integrations like this in the Harden Windows Security module.
Improved Auto Updating Experience
Whenever you execute any of the cmdlets, the Harden Windows Security module will verify if there is a newer version available and update itself automatically if needed. You no longer have to repeat your command after the update, as it will resume seamlessly.
Note
When auto updating from version 0.2.7 to 0.2.8, you will see the message "Update successful, please run the cmdlet again.", instead of doing that, please close and reopen your PowerShell tab/window, otherwise you may encounter an error. It is totally harmless though and you won't see it anymore. This is due to a bug in version 0.2.7 that prevents it from properly disposing the secure constant variables. This bug is resolved in version 0.2.8.
Other Changes And Improvements
-Verboseparameter with each cmdlet.Confirm-SystemCompliance.What's Next
Protect-WindowsSecuritycmdletFeel free to open pull requests if you want to contribute by implementing any of the mentioned features.