Applying the SCT to standalone hardened systems?

[Mughal1]

I'm experimenting with the use of the SCT to speed up the hardening process for "elevated risk" servers for my company, such as systems residing within an Internet DMZ.  My tests are currently relegated to the use of Windows 2016.

In my environment, the DMZ placed systems would likely be standalone and not members of any domain.  The SCT for Win10/Win2016 includes three main processing scripts for the application of the relevant GPO content to the targeted system:

-) Client_Install.cmd

-) Domain_Controller_Install.cmd

-) Member_Server_Install.cmd

Is there any guidance as to which particular processing script I should use for my standalone application on the target system?  None of the "names" for the processing scripts above exactly match my scenario.

Thanks,

Tariq

[#2]

As mentioned before, I was unclear as to which particular script to run as part of the SCT distribution for my particular scenario. None of them seemed to effect a single shot set of security changes I was looking to have updated on my target test Win2016 system.

Anyway, I decided to poke around a bit and see what I could test out and modify using the tools that were provided. Figured I'd share.

The main tools/content I used to test things out where:

1. A test Win2016 base standalone instance (Hyper-V VM, with a checkpoint set just prior to appying SCT modifications so I could revert easily)
2. PolicyAnalyzer 4.0
3. LGPO.exe 3.0
4. The GPO's folder from the "Windows 10 Version 1607 and Windows Server 2016 Security Baseline" zip

I came to understand from a review of the included baseline scripts (Client_Install.cmd, Member_Server_Install.cmd, etc.) that all of the "security update" content pertaining to targeted system hardening was encompassed within the baseline GPOs folder. The GPOs subfolder names however, didn't give me any insight into what changes were applied per GPO.

I ended up using the PolicyAnalyzer tool to gain that understanding. The tool does have a setting under the "Add" section for "File / Add files from GPO(s)...". I pointed PolicyAnalyzer to each GPOs  subfolder and obtained a listing of the general security "topic" for each GPO folder (IE11 changes, Windows Defender changes, etc.). I took those entries and poppped them into a Word doc - I've attached for review.

At the time, I also did a quick review of what security topic content was labeled as pertaining to Windows 2016, Windows 2016 Domain Controllers and Windows 10 and then labeled the content in the doc. I was likely going to shy away from anything expressly labeled as for Domain Controllers or Windows 10, against my particular standalone 2016 system hardening goal.

I now wanted to gain an understanding of the "changes" that each GPO made to my test system. For that, I started an assessment loop using the following process:

1. I ran PolicyAnalyzer on my base unhardened Win2016 Hyper-V VM, running "Compare to Effective State" mapped against the "MSFT-Win10-v1607-WS2016-FINAL" ruleset to establish an initial baseline. This resulted in the creation of an "EffectiveState_xxx" policy entry that could be reviewed/compared later.
2. I reviewed the content of the GPO "security topics" document I had created, picking out the relevant GPOs subfolders I wanted to test with.
3. From an admin powershell prompt on my test system (with all the relevant SCT tools copied locally), I would cd into the relevant GPOs named subfolder and then run "LGPO.exe /g ." to process/apply the content contained within that GPO subfolder to my test system.
4. After the application of the specific GPOs subfolder content using LGPO.exe was complete, I would re-run PolicyAnalyzer, again running "Compare to Effective State" mapped against the "MSFT-Win10-v1607-WS2016-FINAL" ruleset. This would result in an additional named/dated "EffectiveState_xxx" policy in Policy Analyzer.
5. From PolicyAnalyzer, I would then check off the newly created "EffectiveState_xxx" policy, the earlier baseline-based "EffectiveState_xxx" policy as well as the "MSFT-Win10-v1607-WS2016-FINAL" ruleset and then use the "View/Compare" button - I would then have a before/after comparison of the security settings that had been changed to see what that GPO actually did.

I kept re-performing steps 2-5, selecting a new GPOs subfolder at each run for application against the test system and then comparing. As the tests progressed, I shifted from comparing against the original baseline "EffectiveState_xxx" file to comparing against the last several "EffectiveState_xxx" runs to keep seeing the modifications that were being done.

At the end of it all, I had a listing of each specific GPO and a fairly good idea of what each did from a hardening standpoint against the targeted system.

The GPO's that I decided to make use of for the my newly created Standalone2016_Harden.cmd script are as follows:

• GPO subfolder: {07177AF8-97DF-407D-89A6-C875CD1784BC}
  Security Topic: IE11 - Computer
• GPO subfolder: {088E04EC-440C-48CB-A8D7-A89D0162FBFB}
  Security Topic: Win2016 - Member Baseline
• GPO subfolder: {1D2C9D38-6BB1-4C90-B5EB-2850EA18AE06}
  Security Topic: Win2016 - Domain Security
• GPO subfolder: {4095647A-14FE-4CE4-955A-F2311B0D62D1}
  Security Topic: Win10/2016 - Defender
• GPO subfolder: {714FD77E-8FDD-4CB0-B3F7-FF49815473FF}
  Security Topic: Win10/2016 - CredentialGuard
• GPO subfolder: {9C87270F-7704-41D9-A76D-C8B9ADB1794A}
  Security Topic: Win2016 - Member Server Baseline
• GPO subfolder: {B0AA555D-B555-4832-9BA6-2D5A973A7B92}
  Security Topic: IE11 - User

I'd imagine a similar process could be used for other hardening attempts against other potential SCT based systems/solutions.

Hope this helps.

Tariq

[#3]

OK, more updates.

Upon additional review, all of the GPO's that I'd selected were actually already included in the Member_Server_Install.cmd script.

The reason why I'd gone down this weird path was that when I tried to apply the "Member_Server_Install.cmd" script, some of the security settings that I'd expected to be modified were not being modified.  Things like the Audit Policy settings or the System Access settings - the script would run, wouldn't generate any errors but the settings would remain unmodified from their original default values.

The two main GPO subfolders that didn't seem to be triggering were:

GPO subfolder: {088E04EC-440C-48CB-A8D7-A89D0162FBFB}
Security Topic: Win2016 - Member Baseline

GPO subfolder: {9C87270F-7704-41D9-A76D-C8B9ADB1794A}
Security Topic: Win2016 - Member Server Baseline

I'd extracted the baseline zip file to c:\Users\Administrator\Downloads, which meant that the total filepath just to get to the baseline content (GPOs, Local_Script, etc.) was:

C:\Users\Administrator\Downloads\Windows 10 Version 1607 and Windows Server 2016 Security Baseline\Windows-10-RS1-and-Server-2016-Security-Baseline

On a lark, I shifted the "Windows-10-RS1-and-Server-2016-Security-Baseline" folder to the root of c:\ and re-ran.  All of the expected script processing ran fine - including the Audit Policy and System Access settings.  I'm guessing now that the path size was somehow violating the max size limits and was mucking with the script run.

I feel kinda sheepish at this point - but I guess it was a good troubleshooting exercise :)

Tariq

[#4]

@Mughal1 -

The Windows baseline zip file downloads each include a "Documentation" folder with a big spreadsheet listing all the available GPO settings, and columns showing the baseline settings for Win10, Windows Server Member Server, and Domain Controller. In addition, the DC column includes conditional formatting that puts a blue background in the cells that differ from the corresponding Member Server setting.

I also recommend having a look at the scripts that come with the newest Windows baselines. At some point (I don't remember which was the first baseline we did it in), we made a single script that handled all Windows versions, and also included options to adjust settings for non-joined systems by removing some of the restrictions on local accounts.

Also have a look at the MapGuidsToGpoNames.ps1 script in the Scripts\Tools folder -- given a directory containing a bunch of GUID-named GPO backups, MapGuidsToGpoNames.ps1 will tell you the names of the GPOs in each. Have a look in the Baseline-ADImport and Baseline-LocalInstall scripts in the newer download packages for examples of how it can be used.