Blog

July 24, 2023

Why You Should Avoid Windows Group Policy Management for CIS Compliance

Rajesh Radhakrishnan
Rajesh Radhakrishnan

Configuration Management

Windows Group Policy Management is the default — but that doesn’t mean it’s the right fit for your organization when it comes to cybersecurity and compliance. In this blog, we’ll look specifically at the current standard for compliance through CIS benchmarks and offer up a new way to approach policy management without the default. 

Table of Contents: 

What is Group Policy Management? 

Group Policy Management is a way to describe the automatic grouping of Group Policy Objects (GPOs), which allows admins to centrally manage configurations for users and devices to adhere to compliance policies and other internal regulations from a central location.

The out-of-the-box nature of Group Policy Management appeals to IT teams looking to enforce compliance policies across an org with different roles, devices, and security requirements. In theory, Group Policy Management seems like an easy way to kill multiple compliance birds with one stone — until of course, the theory becomes practice. 

What are CIS Benchmarks? 

CIS benchmarks provide detailed and prescriptive guidelines for securing various software and operating systems, including popular platforms such as Windows, Linux, and macOS. These benchmarks are developed and maintained by the Center for Internet Security (CIS), a nonprofit organization.

Cybersecurity and compliance policies are the backbone of any organization's security and regulatory framework. The primary goal of CIS benchmarks is to establish a baseline of security configurations and best practices that organizations can follow to improve the cybersecurity and compliance posture of all their systems. But, how are they enforced within the structure of Group Policy Management?

📋 Compare agent vs. agentless to see how they stack up for secure infrastructure automation >>

For Windows systems, CIS benchmarks can be implemented in two ways: 

  1. Via Group Policy 
  2. CIS-hardened virtual machine images

However, as new projects get approved and new systems are added, the one-size fits all approach to securing all the systems doesn’t work. Exceptions must be added at the Application Level, which is tricky to manage. 

Managing Exceptions to the Group Policy 

Here are some examples, from the CIS Windows Benchmarks [1], as to why exceptions between Windows Domains and Applications are needed: 

  • 2.2.28 (L2) Ensure 'Log on as a batch job' is set to 'Administrators' (Automated): This setting is set to 'Administrators' during Server hardening or as part of a pre-hardened image. However, this setting must be set to ‘undefined’ or ‘configurable’ for Microsoft IIS. 
  • 2.3.10.10 (L1) Ensure 'Network access: Restrict clients allowed to make remote calls to SAM' is set to 'Administrators: Remote Access: Allow' (Automated): This setting is set to 'Administrators' during Server hardening or as part of a pre-hardened image. However, this setting will require domain accounts to be added per Domain. 
  • 2.2.23 (L1) Ensure 'Generate security audits' is set to 'LOCAL SERVICE, NETWORK SERVICE' (Automated): This setting is set to 'LOCAL SERVICE, NETWORK SERVICE’ during Server hardening or as part of a pre-hardened image. However, this setting needs to allow users to set their values.

In situations where exceptions need to be added, the only way to add an exception in Group Policy Management is to create a sub-organizational unit (sub-OU). 

  • Same settings can cause conflict: If two Group Policy Objects (GPOs) have the same setting, the setting linked lower in the Active Directory will take precedence. This can cause problems if you are not aware of the conflict in the first place. 
  • Troubleshooting can be difficult: It is hard to track down problems within a Group Policy when Objects can be affected by the order they are processed, the individual user permissions, and the Active Directory replication status. 
  • Changes are slow to apply: The more users and devices, the longer it will take to apply changes broadly across a system — especially if the change is time-sensitive. 
  • Managing exceptions is challenging: The more Group Policy Objects you have as your organization grows, the more difficult it will be to make changes and troubleshoot problems. 

These problems start to appear in day-to-day functions and across different teams: 

  • Issues with policy drift: When IT teams publish regular updates to their internal compliance policy, the Infrastructure & Operations (I&O) team has the arduous task of looking at the exceptions per domain and finding a way to fit them into the new compliance policy. This can cause a drift between the old way of management and the new policy enforcement. 
  • Exceptions cause multiple sub-hierarchies: Exceptions manifest in different ways, at the Server level or at the Application level. Adding these exceptions at different levels of the hierarchy causes setting sprawl. This occurs when Operations teams set up only the base OUs, and each organization owns its group policies. 
  • Duplication of base group policy objects: Group Policy Objects are not like software code — you can’t separate settings into data and code layers. The code layer refers to a single code base that manages settings for different OSes. You must decide which parts of the code to execute by providing the right parameter values in the data layer. The absence of this separation causes a settings duplication problem. For example, there will be a Base Group Policy Object settings for Windows 2012 R2 server and another for Windows 2019. 

Using Infrastructure-As-Code for Implementing CIS Compliance

We’ve explored the problems with Group Policy Management and using pre-hardened images. Let’s take a look at the alternative: using infrastructure-as-code (IaC) to manage your exceptions in a cleaner, re-usable, easier-to-troubleshoot process. 

Why is infrastructure-as-code (IaC) better? 

  • IaC is system-based: This feature makes the IaC code inherently cross-domain. Contrast with using GPOs where GPO settings/hierarchies have to be maintained on different domain controllers. 
  • IaC is version-controlled: For GPOs, customers need to buy extra tools like the Microsoft Advanced Group Policy Object Management (AGPM) feature for version management. 
  • IaC code is easier for auditors to review: For auditors, Infrastructure & Operations (I&O) teams can easily demonstrate that the code makes changes. The whole change management process is what auditors prefer to see.
  • IaC is designed for maximum re-usability: IaC offers a clean way of separating the Code and Data Layers. The Data layer, like Puppet-Hiera, allows users to provide parameter values to the Code layer and supports different exceptions based on per system, business unit, data center, etc., with a single code base. 
  • GPO users need manual steps to compile reports, but IaC doesn’t: For example, to ensure a system is compliant when using group policy, the Administrator must manually parse the Windows Event Viewer to ensure group policy was applied successfully on each system. The Administrator will then need to extract all GPOs assigned to that system and manually compare with the results found in the Event Viewer. Then compile the report. With Puppet, the Administrator can confirm that all the compliance settings are enforced via the latest Puppet Agent report. The Puppet Agent report shows the exact state of the managed resources on the system.  

This is one of the reasons that Puppet is the best designed IaC solution on the market. With Puppet, you only need to look at the system’s latest Puppet Agent report to know the exact state of the managed resources on the system. 

📃 Download the White Paper: Accelerate Digital Transformation with an Infrastructure-as-Code Strategy. 

Infrastructure-as-Code vs. Group Policy for Audits 

In addition to the ease of managing exceptions, another key reason for moving to IaC from Group Policy Management is better report generation. The compliance report generation step usually becomes the bottleneck during a compliance audit. To understand why, let us review the infrastructure-related compliance audit process. 

An auditor typically follows these steps: 

  1. The auditor will pick a random set of systems to audit, and then request a compliance report on that particular set of systems. 
  2. If the report is generated quickly and contains all the answers the auditor is looking for, the auditor will complete the audit quickly. 
  3. However, the audit process will be delayed if the report generation takes a long time and/or the report needs more consistency. 
  4. If there are many compliance failures in the small random set of servers, the auditor will increase the set of systems to be tested. The audit will go on. 

IaC through Puppet addresses these challenges by:

  • Maintaining a historical record of all changes made to a system by the Puppet Agent in the form of Puppet Agent run reports, which are easily accessible via the Puppet Enterprise Console or via the Puppet Enterprise API. 
  • Puppet Agent run reports offer a resource-by-resource account of what changes occurred on the system, as well as whether the change was intentional, corrective (i.e. fixed configuration drift), or several other states. 
  • Showcasing continuous enforcement is already a part of the solution to the auditor, such as immediately deploying a reset and alert if the settings are tampered with. 
  • New compliance settings can be deployed in stages, testing and then deploying the changes to production systems. 

Infrastructure-as-Code for Delegated Code Development 

The Infrastructure & Operations (I&O) team can only manage some of the applications and user settings in large companies. Typically, I&O teams will provision a machine with baseline Group Policy Object settings and delegate the work of adding exceptions to the various internal teams. 

As you can imagine, this delegation of work needs to be clarified during the audit process.

Infrastructure-as-code provides a clean way of using software best practices of identifying modules and interfaces so that IaC code developers and the I&O team can share a common environment while still working independently. 

Each team puts their code into IaC modules and only the systems they own will get their code changes. The process of adding exceptions and generating reports for their code will also be the same for every internal team. 

Adopting Infrastructure-as-Code 

Ditch Group Policy Management — it's easy to get started on your compliance journey via Puppet. No matter what your compliance goals are, no matter how large your organization is or how many users and devices you’re managing, Puppet simplifies compliance management by implementing your desired end state with infrastructure-as-code. 

Want to see the infrastructure-as-code difference in action? Try a free demo of Puppet’s Compliance solution to get started:

👉TRY PUPPET FOR COMPLIANCE

References: https://downloads.cisecurity.org/#/ - Windows 10, 11, 2019 benchmarks