Continue your mission
Endpoint hardening is the practice of configuring operating systems, applications, and firmware to reduce the attack surface by disabling unnecessary services, removing unnecessary software, applying security configurations, and enforcing baseline standards that eliminate common attack vectors.
# Endpoint Hardening
Endpoint hardening is the practice of configuring operating systems, applications, and firmware to reduce the attack surface by disabling unnecessary services, removing unnecessary software, applying security configurations, and enforcing baseline standards that eliminate common attack vectors. Hardening takes a default installation (configured for ease of use, not security) and transforms it into a secured configuration (configured to resist attack at the cost of some convenience).
Default configurations are insecure by design. Operating systems ship with services enabled that most users never need. Applications install with default credentials that administrators often forget to change. Network devices ship with management interfaces accessible from every network segment. Each default is a convenience that becomes an attack vector. Hardening systematically identifies and eliminates these defaults.
The discipline is straightforward but operationally intensive. A single Windows endpoint has hundreds of configurable security settings: local policies, registry values, service configurations, firewall rules, audit settings, and application permissions. Multiplied across thousands of endpoints, the configuration surface is enormous. Hardening at scale requires automation (GPO, Intune, Ansible, Chef, Puppet), baseline standards (CIS Benchmarks, DISA STIGs), and continuous compliance monitoring (detecting and remediating configuration drift).
CIS Benchmarks. The Center for Internet Security publishes configuration benchmarks for over 100 technology platforms: Windows (Desktop, Server), Linux (Ubuntu, RHEL, Amazon Linux), macOS, cloud platforms (AWS, Azure, GCP), network devices (Cisco, Palo Alto, Fortinet), databases (SQL Server, PostgreSQL, Oracle), and applications (Microsoft 365, Google Workspace, Apache, IIS).
CIS Benchmarks define two implementation levels. Level 1: essential security configurations that can be applied broadly without significant operational impact. Level 2: advanced configurations that provide stronger security but may affect functionality or compatibility. Most organizations target Level 1 as the baseline and selectively apply Level 2 settings for high-security systems.
Each benchmark setting includes: the recommended value, the rationale (why this setting matters for security), the audit procedure (how to check the current value), and the remediation procedure (how to set the recommended value). This documentation enables teams to understand what they are configuring and why.
DISA STIGs (Security Technical Implementation Guides). Published by the Defense Information Systems Agency for U.S. Department of Defense systems. STIGs are more prescriptive than CIS Benchmarks and are mandatory for DOD environments. STIGs are organized by severity: Category I (critical, must be addressed immediately), Category II (important, should be addressed within a defined timeline), and Category III (informational, should be addressed as resources permit).
STIGs are required for CMMC compliance and recommended for any organization that handles CUI (Controlled Unclassified Information) under NIST 800-171. Organizations pursuing DOD contracts should harden to STIGs rather than CIS Benchmarks because STIGs are the DOD standard.
Vendor hardening guides. Technology vendors publish their own hardening recommendations: Microsoft Security Baselines (deployed through Intune or GPO), Red Hat's Security Guide, AWS Well-Architected Security Pillar, and Azure Security Benchmark. Vendor guides are tailored to the specific platform and complement CIS Benchmarks and STIGs.
Windows endpoints (desktops and laptops) are the most common target for cyberattacks because they are the most common endpoint in enterprise environments. Key hardening areas:
Credential protection. Enable Credential Guard (isolates LSASS in a virtualization-based security container, preventing credential dumping from memory). Enable LSA protection (runs LSASS as a Protected Process Light, restricting which processes can interact with it). Disable WDigest authentication (prevents cleartext credential caching in memory). These three settings directly address the credential theft techniques (Mimikatz, LSASS memory dumping) that every ransomware operator uses.
Application control. Windows Defender Application Control (WDAC) or AppLocker restricts which applications can execute on the endpoint. Allowlist-based application control (only approved applications can run) is the strongest endpoint hardening control because it prevents the execution of any unauthorized code, including malware, attack tools, and unauthorized software. The operational overhead is significant (every approved application must be in the allowlist), but for high-security environments, application control eliminates the most common attack execution vector.
PowerShell security. Configure PowerShell Constrained Language Mode (restricts PowerShell to a limited set of commands), enable PowerShell Script Block Logging (logs every PowerShell command executed), enable PowerShell Module Logging, and configure PowerShell Transcription (records complete PowerShell sessions). PowerShell is the most commonly abused living-off-the-land tool in enterprise attacks. These settings do not disable PowerShell (which would break administrative workflows) but restrict and log its use so that malicious PowerShell activity is detectable.
Local administrator management. Disable the built-in local Administrator account or rename it (preventing brute force against a known account name). Implement LAPS (Local Administrator Password Solution, now Windows LAPS in Windows 11/Server 2025) to set unique, randomized local admin passwords on each endpoint, stored in Active Directory and rotated automatically. LAPS prevents a credential compromise on one endpoint from granting local admin on every other endpoint (the lateral movement technique that uses shared local admin passwords).
Service and feature reduction. Disable unnecessary services (Remote Registry, Windows Remote Management if not needed, Print Spooler on systems that do not print). Remove unnecessary features (SMBv1, PowerShell v2, Internet Explorer mode if not required). Each disabled service and removed feature is an attack surface eliminated.
Audit logging. Configure Windows Advanced Audit Policy to log: account logon events, logon events, object access, privilege use, process creation (with command line logging), and policy changes. These events feed the SIEM and provide the telemetry that threat detection and forensic investigation require.
Linux servers require different hardening approaches:
SSH hardening. Disable root login via SSH. Require key-based authentication (disable password authentication). Restrict SSH access to specific user groups and source IP ranges. Configure idle session timeout. Change the default SSH port (security through obscurity, minor but reduces automated scanning noise).
Kernel hardening. Enable ASLR (Address Space Layout Randomization). Disable unnecessary kernel modules. Configure sysctl parameters for network hardening (SYN flood protection, ICMP redirect rejection, IP spoofing protection). Apply SELinux or AppArmor mandatory access control policies.
Service minimization. Install only the packages required for the server's function. A web server does not need a mail server, a database client, or development tools installed. Each unnecessary package is a vulnerability surface.
File system permissions. Restrict permissions on sensitive files and directories. Ensure /etc/passwd, /etc/shadow, and /etc/sudoers have appropriate ownership and permissions. Mount /tmp with noexec,nosuid options to prevent execution of files from temporary directories (a common malware staging technique).
Hardening is not a one-time project. Configurations drift: an administrator disables a security setting during troubleshooting and forgets to re-enable it. A software update resets a hardened configuration to default. A new application installation requires a configuration exception that is never reviewed or revoked.
Configuration drift is the gradual erosion of hardened configurations back toward insecure defaults. Without continuous monitoring, drift is invisible until the next audit reveals that 30% of endpoints have deviated from the baseline.
Configuration compliance monitoring tools (Microsoft Intune compliance policies, CIS-CAT Pro, Qualys Policy Compliance, Chef InSpec, SCAP scanners) continuously compare endpoint configurations against the defined baseline and report deviations. CDA's APC (Autonomous Posture Command) methodology treats configuration compliance as a real-time posture metric: drift is detected immediately, not at the next quarterly assessment.
Every unnecessary service, enabled feature, default credential, and permissive configuration is an attack surface. A default Windows installation with all features enabled, no credential protection, and unrestricted PowerShell provides an attacker with dozens of techniques that a hardened endpoint eliminates. Hardening does not make the endpoint invulnerable. It makes the attacker's job harder, slower, and noisier, which gives the SOC more time to detect and respond.
Endpoint hardening is required by every major compliance framework. CIS Controls v8 Control 4 (Secure Configuration of Enterprise Assets and Software) specifically addresses hardening. NIST CSF 2.0 PR.PS (Platform Security) includes secure configuration. PCI DSS Requirement 2 (Apply Secure Configurations to All System Components) mandates hardening. CMMC includes configuration management practices. ISO 27001 A.8.9 (Configuration Management) requires secure baselines.
Auditors verify hardening by comparing system configurations against the defined baseline (CIS Benchmark, STIG, or organizational standard). Systems that deviate from the baseline without documented, approved exceptions are findings.
Several hardening controls directly prevent the lateral movement techniques that ransomware and APT actors depend on: Credential Guard and LSA protection prevent credential dumping. LAPS prevents shared local admin passwords. Application control prevents malware execution. PowerShell restrictions prevent malicious scripting. Network segmentation (enforced through host-based firewalls) restricts which systems each endpoint can communicate with. Together, these controls transform the endpoint from an open platform that an attacker can freely exploit into a restricted environment where every attack technique encounters a barrier.
Endpoint hardening sits in the SPH (Security Posture and Hygiene) domain of the Planetary Defense Model. SPH is the terrain: the ground the organization defends on. Hardening is terrain preparation: digging trenches, building fortifications, clearing fields of fire. An unhardened endpoint is an open field. A hardened endpoint is a fortified position.
CDA's Autonomous Posture Command (APC) governs endpoint hardening as a continuous posture control. "Your posture adapts. Your hygiene never sleeps." Configuration compliance is monitored continuously. Drift is detected and remediated without waiting for the next audit cycle. The posture score reflects real-time configuration compliance across every managed endpoint.
SPH-B02 (Endpoint Hardening Standards, 32 estimated hours) is the mission that builds the hardening program: select the baseline standard (CIS Benchmark Level 1 for most organizations, STIG for DOD/CMMC), customize the baseline for the organization's environment (documenting exceptions with business justification), deploy the baseline through automation (GPO, Intune, Ansible), configure compliance monitoring, and establish the drift remediation workflow.
The mission is 32 hours because hardening touches every endpoint in the environment and requires careful testing before deployment (a hardening setting that breaks a business application must be identified and excepted before organization-wide rollout). CDA deploys hardening in phases: pilot group, early adopters, broad deployment, with monitoring at each phase to catch compatibility issues before they affect the entire organization.
Three connected missions: SPH-R02 (Configuration Baseline Assessment, 20 hours) assesses the current state before hardening. SPH-H01 (Configuration Drift Remediation, 16 hours) addresses drift detected after deployment. SPH-B02 is the build. SPH-R02 is the assessment. SPH-H01 is the ongoing maintenance.
Word count: 1,974
CDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.