4.5 Secure Baseline Configuration & System Hardening

4.5 Secure Baseline Configuration & System Hardening

Unpatched vulnerabilities, insecure default settings, and unauthorized configuration drift represent the most common attack vectors exploited by threat actors. Within the ISC2 CGRC credential and the NIST Risk Management Framework (RMF), implementing robust configuration management and system hardening controls—governed primarily by NIST SP 800-128 (Guide for Security-Focused Configuration Management) and the NIST SP 800-53 Rev. 5 Configuration Management (CM) family—is a mandatory requirement for achieving and sustaining an Authority to Operate (ATO).

---

Establishing Secure Configuration Baselines (CM-2, CM-6)

A Secure Baseline Configuration is a formally documented, tested, and management-approved technical build standard for an information system and its constituent components (operating systems, database engines, web servers, hypervisors, network switches, and firewalls).

┌─────────────────────────────────────────────────────────────────────────────┐
│                     CONFIGURATION BASELINE LIFECYCLE                        │
│                                                                             │
│   1. Source Selection: DISA STIGs, CIS Benchmarks, NIST NCP (SP 800-70)     │
│             │                                                               │
│             ▼                                                               │
│   2. Build Hardening: Apply templates, scripts, Golden Master Images, IaC   │
│             │                                                               │
│             ▼                                                               │
│   3. Automated Audit: SCAP validation (XCCDF checklists & OVAL queries)     │
│             │                                                               │
│             ▼                                                               │
│   4. Change Control: CCB review, CMDB logging, drift detection & remediation│
└─────────────────────────────────────────────────────────────────────────────┘

Core Configuration Objectives

• Attack Surface Minimization: Disabling all unused ports, protocols, services, and software compilers.
• Least Functionality (CM-7): Ensuring systems are configured to provide only essential capabilities required to execute authorized mission functions.
• Predictable Reproducibility: Enabling automated, rapid provisioning of identical, pre-hardened computing nodes across cloud and on-premises environments.
• Continuous Verifiability: Providing automated machine checks to detect and alert on unauthorized configuration changes (configuration drift).

---

Authoritative Hardening Standards & Repositories

GRC practitioners must leverage authoritative, consensus-based security baselines tailored to their organizational environment:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     MAJOR BASELINE CONFIGURATION SOURCES                    │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. DISA STIGs (DoD Mandatory)                                              │
│     • Severity Categories: CAT I (Critical), CAT II (Medium), CAT III (Low)  │
│     • Enforced across Department of Defense and National Security Systems   │
├─────────────────────────────────────────────────────────────────────────────┤
│  2. CIS Benchmarks (Global Commercial & Public Sector Standard)             │
│     • Level 1: Essential baseline, low operational risk, no performance hit │
│     • Level 2: Defense-in-depth, high-security enclaves, potential friction │
├─────────────────────────────────────────────────────────────────────────────┤
│  3. NIST National Checklist Program (NCP / SP 800-70 Rev. 4)                │
│     • Central federal clearinghouse of SCAP-validated configuration guides  │
└─────────────────────────────────────────────────────────────────────────────┘

1. DISA Security Technical Implementation Guides (STIGs)

Published by the Defense Information Systems Agency, STIGs represent the mandatory hardening standard for all Department of Defense (DoD) systems and are widely adopted across federal civilian agencies. STIG findings are categorized by strict severity levels:

• CAT I (High Severity): Any vulnerability or configuration error that will directly result in an immediate, catastrophic compromise of the system, grant unauthorized root/administrator access, or allow complete bypass of primary security perimeters (e.g., default administrator password enabled, anonymous FTP enabled with write access). ATO Blocker: CAT I findings must be remediated or formally mitigated before system authorization.
• CAT II (Medium Severity): Any vulnerability or misconfiguration that significantly increases the potential for unauthorized system exploitation, data exfiltration, or operational degradation (e.g., missing mandatory security audit logging, password complexity parameters not enforced).
• CAT III (Low Severity): Any minor weakness that degrades overall security posture, increases vulnerability to compromise over time, or hinders defensive auditing (e.g., informational login banners missing exact legal warning text).

2. Center for Internet Security (CIS) Benchmarks

CIS Benchmarks are globally recognized, consensus-based configuration guidelines spanning over 100 technology platforms across operating systems, cloud providers, and container runtimes. They provide two distinct hardening tiers:

• CIS Level 1 Profile: Foundational security configurations intended to be applied rapidly with minimal operational friction, zero performance degradation, and no adverse impact on core business applications.
• CIS Level 2 Profile: Advanced, defense-in-depth hardening configurations designed for high-security environments, classified enclaves, or critical infrastructure where security strictly supersedes operational convenience (e.g., disabling legacy PowerShell modules, enabling strict kernel module signing).

3. NIST National Checklist Program (NCP / SP 800-70 Rev. 4)

Managed by NIST under the mandate of the Cyber Security Research and Development Act of 2002, the NCP provides a centralized, publicly accessible repository of detailed security checklists for commercial and open-source software, facilitating automated compliance verification.

---

The Security Content Automation Protocol (SCAP)

Auditing thousands of configuration settings manually across enterprise server fleets is operationally impossible. The Security Content Automation Protocol (SCAP)—standardized under NIST SP 800-126 Rev. 3—provides a suite of open, interoperable specifications that automate vulnerability scanning, configuration assessment, and policy compliance reporting.

┌─────────────────────────────────────────────────────────────────────────────┐
│                        SCAP SPECIFICATION ARCHITECTURE                      │
│                                                                             │
│  Standardized Enumerations:                                                 │
│  ├── CCE (Common Configuration Enumeration): Unique configuration IDs       │
│  ├── CPE (Common Platform Enumeration): Standard hardware/OS/app names      │
│  └── CVE (Common Vulnerabilities & Exposures): Standard software flaw IDs   │
│                                                                             │
│  Scoring & Assessment Languages:                                            │
│  ├── CVSS (Common Vulnerability Scoring System): Quantitative severity (0-10)│
│  ├── XCCDF (Extensible Configuration Checklist Description Format): Rules   │
│  ├── OVAL (Open Vulnerability & Assessment Language): Technical test queries│
│  └── ARF (Asset Reporting Format): Machine-parsable assessment reports      │
└─────────────────────────────────────────────────────────────────────────────┘

SCAP Core Specifications

---

Hardening Enforcement and Modern Infrastructure

Modern enterprise environments enforce configuration baselines using automated, immutable infrastructure patterns rather than manual server administration:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     IMMUTABLE INFRASTRUCTURE HARDENING FLOW                 │
│                                                                             │
│   Code Repository (IaC)  ──► Automated Pipeline (STIG/CIS) ──► Hardened AMI │
│   (Terraform / Ansible)      (Packer / SCAP Scanner)           (Golden Base)│
│                                                                      │      │
│                                                                      ▼      │
│   Drift Detected! ◄── Automated Audit (Tripwire / AWS Config) ◄── Production│
│   (Auto-Tear Down & Re-deploy Hardened Golden Image)               Instances│
└─────────────────────────────────────────────────────────────────────────────┘

1. Golden Master Images & Base Templates

• Pre-hardened, pre-scanned virtual machine images (AMIs, VHDs) and base container images (Dockerfiles). Golden images have all STIG/CIS rules baked in, unnecessary utilities removed, and security agents pre-installed before deployment.

2. Infrastructure as Code (IaC) Enforcement

• Tools such as Ansible, Terraform, Puppet, and Chef define configuration baselines as version-controlled code. This guarantees that 1,000 servers deployed across multiple cloud regions adhere to an identical, auditable configuration standard without manual intervention.

3. Configuration Drift Detection & Automated Remediation

• Configuration Drift occurs when ad-hoc manual changes, unapproved software patches, or localized troubleshooting modify a server's runtime state away from the approved baseline.
• Continuous monitoring agents (e.g., Tripwire, Wazuh, AWS Config, Microsoft Defender for Cloud) continuously compare running assets against the approved baseline. When drift is detected, automated playbooks alert the SOC, trigger automated self-healing scripts, or destroy the drifted instance and redeploy a pristine golden image.

4. Practical System Hardening Playbook

• Ports, Protocols, and Services Management (PPSM - CM-7): Explicitly disable legacy and insecure protocols (e.g., Telnet, FTP, TFTP, SMBv1, HTTP). Maintain a whitelist of authorized ports (e.g., 443, 22, 8443).
• Account and Credential Hardening: Eliminate or rename default administrative accounts (admin, administrator). Disable guest accounts. Enforce strict password complexity and session timeouts.
• Kernel and OS Protection: Enable mandatory access controls (MAC) such as SELinux (enforcing mode) or AppArmor. Enable Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) to prevent buffer overflow exploitation.

---

Real-World RMF Scenario: The STIG CAT I ATO Escalation

Scenario: During a pre-authorization automated SCAP compliance scan of a newly deployed enterprise financial database, the SCA discovers a DISA STIG CAT I finding: the database administrative account is configured with a default factory password, and direct SSH remote root login is permitted across the external boundary.

GRC Action: The SCA immediately flags the finding as an ATO Blocker. The system cannot be granted an Authority to Operate with an unmitigated CAT I vulnerability. The engineering team implements an Ansible hardening playbook to disable remote root SSH login, integrates enterprise PIV/CAC authentication for DBAs, and re-scans the system with SCAP Compliance Checker (SCC). The clean scan report is ingested into the Security Assessment Report (SAR) to allow the Authorizing Official to issue the ATO.

---

Common Exam Traps

• ⚠️ Trap: Confusing XCCDF with OVAL. XCCDF is the XML document that defines the checklist and rule structure; OVAL is the underlying XML testing language that executes the actual technical query against the machine state.
• ⚠️ Trap: Confusing CCE (Common Configuration Enumeration) with CVE (Common Vulnerabilities and Exposures). CCE identifies configuration settings (e.g., minimum password length); CVE identifies software vulnerabilities and flaws (e.g., Log4Shell).
• ⚠️ Trap: Assuming CIS Level 1 benchmarks are intended only for low-impact systems. CIS Level 1 benchmarks are foundational baselines designed for enterprise-wide deployment across all systems without causing operational disruption.