06-09-2023 06:19 AM
Hi Folks
This isn't particularly new, but I got a feeling that there's a good moment to share some updates I was working on recently.
Last week I wrote about the same topic for macOS here and a while back @shawnsong and myself published a 'Bulk-Importer for the "Windows - Advanced: Custom Registry Keys Policy" which can, for example, manage policies for Zoom (separate article here).
So, why bring this up again?
The previous Bulk-Importer for Windows Policies is limited to a single Registry File as a source and that's not ideal, especially not if you want juggle around with CIS Benchmarks - which we covered here previously by using HardeningKitty.
The big constraint coming up here as that CIS Benchmarks and the respective controls for Windows are exhaustive. In short: 500ish settings in one single policy are not manageable at all, especially because it's very unlikely that you want to enforce all of these on your devices.
...and what's 'wrong' with the approach by using HardeningKitty?
It's great to begin with (also a really great project by itself), but it's purely script-based and therefore not a policy per se. Policies are managed in GPO-style and that makes them more robust.
...and how do we get to policies now?
Well, first we need to conclude that we can't enforce ALL settings via policies. Means, you are currently limited to settings which are with the Hives of HKLM (see the KB-article) and what can be cover by other means like a global Password Policy - for example.
However - and I don't have the exact percentage on hand right now - you can enforce the majority of controls this way.
The approach here I took was the following on a high-level:
Some more details on the scripts.
First script: "JumpCloud - HardeningKitty to multiple REG.ps1"
- Downloads the CSV of your choice (adjust accordingly in the script)
- Parses out the HKLM-content and as well as the Control ID and the Name
- Creates a file for the controls in buckets, i.e. 5.4., 5.41. and so on
- Within the REG-file itself a comment is added before each setting, i.e.:
5.34.1 : Windows Error Reporting Service (WerSvc)
This will be used later within the second script while importing the policies.
Second script: "JumpCloud - Bulk REG Importer to multiple Custom Policies.ps1"
- Function: Create-NewPolicy
This function creates a new empty 'Advanced: Custom Registry Policy'
- Function: Update-PolicyWithRegistryKeys
This function then updates the just created policies by feeding the values from the registry-file
- Main script:
Reads the given folder path, consumes the prefix for each policy, calls the API to deliver the payloads
This project is clearly born out of the desire to have segmented policies for benchmarks, but during testing it also worked for any other registry-file. So you can use this for other settings as well with a few minor adjustments for names etc - which you can find in the code. I've mentioned the areas which can be modified.
Some notes:
Especially the import-function is basically a revamp of the initial Import-script mentioned above. I didn't want to reinvent the wheel here (and also didn't wanna bother Shawn too much again).
Also worth mentioning (I said that multiple times before, I guess): I'm not a really good coder, but I'm learning with each new script I'm getting out and it's fun. In addition: yes, I'm making use of Github Copilot, Doug Finke's PowerShellAI-Module and sometimes ChatGPT. It's super helpful and accelerates your 'go to market' dramatically. Important is that you can read and understand what the AI's are giving you - which in term makes you learn again.
I remember that the first Import-Script which Shawn I were working took us days (combined in summary). These two scripts now took me combined over a couple of days way less than 8hrs, 5ish roughly.
As usual, especially when dealing with enforced settings via Policies:
- I would recommend exploring these resources and adapting them to fit your specific needs and environments.
- Please note that while these scripts can be helpful starting points, they will not cover every control in the CIS Benchmarks
- and they might require modification or supplementation to fully meet your needs
- Furthermore, always test any changes in a controlled environment before applying them to production systems to avoid unexpected issues
- Lastly, if your applying these within your organization, in production, be clear about licensing implications and take care of that (check it out on the CIS Website)
Thanks for reading, sharing, commenting 😉
- Juergen
New to the site? Take a look at these additional resources:
Ready to join us? You can register here.