Many users assume that Windows devices are decently secure right out of the box. For personal users, the default Windows security configurations may suffice. However, enterprise endpoints should undergo a much more rigorous series of security configuration. Hardening is a process intended to eliminate a means of attack by patching vulnerabilities and turning off nonessential services. The goal is to literally harden the system against threats. To harden devices, IT administrators typically create master baselines. A baseline is a set of controls that are applicable to information or an information system to meet legal, regulatory, or policy requirements, as well as address protection needs for the purpose of managing risk. Baselines are created, tested, and deployed to workplace endpoints, bringing them up to compliance with the standards used to define the baseline.

Baselines are often created based on industry recognized security standards such as CIS Benchmarks, DISA STIGS, NIST SP 800-53, or Microsoft Security Compliance Toolkit. These standards provide admins with a checklist of configurable Windows security settings, as well as the means for importing them. This way, the admins can easily copy hundreds of security settings directly into their central device management platform, such as Group Policy or Microsoft Intune Configuration.

It is important that organizations start small with their security hardening by deploying baselines to a pilot test group. Since the settings in security baselines are very granular, there is bound to be some kind of intrusion or incompatibility depending on the particular organization’s environment. Starting with a pilot group allows admins to study the effects of security baselines, note any issues that arise, and then tailor the settings. Tailoring is the process by which security control baselines are modified by identifying and designating common controls; applying scoping considerations; selecting compensating controls; assigning specific values to agency-defined control parameters; supplementing baselines with additional controls or control enhancements; and providing additional specification information for control implementation. After the necessary rounds of testing and tailoring, admins should have a fully compatible finished baseline that can then be pushed out to all the organization’s devices.

With Windows, there are several different ways to push out a hardening baseline depending on the network environment being used. Group Policy Management is the classic method for configuring device settings in a Windows domain network. Standards such as CIS Benchmarks and DISA STIGS define the exact path and values to set for each hardening step they outline. Microsoft Security Compliance Toolkit provides importable copies of their baselines so admins can apply the baseline without having to set each setting individually. Group Policy can be used beyond Windows as well. Group Policy is simply a method of configuring the registry for each system. Admins configure the registry settings using an accessible user interface contained in the Group Policy Editor. Settings are displayed in the editor via ADMX/ADML templates. Without them, the configurations can still exist, however they won’t be visible in the Group policy UI. Developers have released ADMX/ADML templates for various applications, allowing hardening baselines to be configured for individual applications in addition to the Windows OS. Chrome, Firefox, Office 365, Zoom, and Windows Defender all have publicly available ADMX/ADML templates for admins to use.

For organizations that use standalone Windows endpoints with no central domain controller, the Group Policy option is still available. The Local Group Policy Editor lets admins define security settings for local systems. Using the LGPO.exe utility contained in the Microsoft Security Compliance Toolkit, an admin can configure a master copy of the baseline on one system, then export it and import it individually on the other Windows systems on the network. Keep in mind that this only works on Windows Pro, Enterprise, and Education versions, as they are the only OS versions that contain the Local Group Policy Editor. Windows Home editions can still have the same hardening baselines configured; however it will need to be done directly through the Registry Editor, which is more time consuming and has a bigger capacity for error. CIS Benchmarks and DISA STIGs provide the necessary registry paths and values in their documentation.

For MDM centric environments, tools such as Microsoft Intune provide their own avenues for hardening devices. Standard Policies can be created under the Device Configuration blade, allowing admins to configure Settings Catalog, Device Restrictions, and Administrative Templates. This is great for admins who want to start from scratch and tailor a very specific baseline for their environment. On the other hand, Intune offers Security Baselines, which are pre-configured templates of recommended hardening controls for Microsoft platforms. Microsoft regularly updates the baselines so that new threats and features are addressed automatically in each one. Updates can be tracked at the Microsoft Security Baselines Blog. Baselines are a good approach for organizations that want a fast deployment of the standard hardening recommendations from Microsoft. However, the sheer volume of different settings may make hunting down problem settings and tailoring them more difficult. Finally, Intune has introduced Security Blades. These allow admins to define security settings for individual workloads rather than at once on a big checklist. Blades exist for Windows Defender, BitLocker Drive Encryption, and Windows Firewall. Using Security Blades allows admins to harden devices in small batches, working one feature at a time.

In addition to security settings, many hardening baselines define requirements for removing certain services and features, as well as installing others. Group Policy provides options for accomplishing this, however more specific tasks may require a different approach. Admins can write PowerShell scripts, which run on the systems and perform the operations defined in the script. Admins could write a script to remove all Windows built in apps, and another script that adds UBlock Origin and HTTPS Everywhere to Chrome. The admins can then deploy these scripts to each endpoint and have them run automatically. Scripting is a more complex task that requires knowledge of scripting languages and the underlying Windows OS.

The status of the endpoint security configuration can be measured and supervised once deployed using the Security Content Automation Protocol (SCAP). Platforms like OpenSCAP or Tenable allow admins to scan the current state of an endpoint against a pre-determined baseline. The SCAP protocol will test what is defined in the baseline against the actual configurations on the device, then return a report showing the admin how compliant the device is. This kind of scanning should be a regular part of an organization’s continuous monitoring and improvement process.

Microsoft has defined the Microsoft Security Configuration Framework, or SecCon Framework, to help admins track the progress of endpoint hardening. The framework defines five levels of security that endpoints in an organization could fall under.

  1. Enterprise Basic Security: The bare minimum-security configuration for any endpoint. These are the most basic security hardening steps applied organization-wide and are intended to be refined as organizations better understand their threat environment and risk appetite.
  2. Enterprise Enhanced Security: These are endpoints that handle any sensitive/confidential data. Controls for these devices will need to be more carefully defined and tested for compatibility with apps and functionality.
  3. Enterprise High Security: These are endpoints that have a unique security context and/or handle data that could severely damage the organization if compromised. This level should be the default for all endpoints in an organization likely to be targeted by highly skilled and well-funded threat actors.
  4. DevOps Workstation: This is a special context for users such as backend developers, or any other role that is a high value target due to the access rights they have on their device.
  5. Administrator Workstation: This is the highest level of endpoint security, reserved for devices that are used to access, configure, and manage critical backend infrastructure such as IAM platforms, servers, and data stores. Also known as Privileged Access Workstations (PAWs), these endpoints are restricted for use only when accessing authorized platforms to perform privileged actions. The security baselines for these systems are typically extreme, with as much functionality removed as possible. For example, an admin may be able to open Google Chrome and sign into a server through an encrypted tunnel, and absolutely nothing more.

Using the SecCon Framework can help organizations better grasp their security hardening needs. By comparing the framework with the documented system security boundaries from Stage 1, organizations can map their endpoints to the levels from SecCon, and then create hardening baselines that are tailored to the security needs of each level.