15.1 Configuration Baselines and Secure Defaults

Where System Hardening Sits on the CC Exam

System hardening is the practice of reducing attack surface (every way a system can be reached or abused) and keeping a system in a safe, known state. On the ISC2 Certified in Cybersecurity (CC) exam, hardening lives inside Domain 5, Security Operations, which is 18 percent of the test.

Know the logistics cold. The current exam outline took effect October 1, 2025, and a refreshed outline is effective September 1, 2026. The exam uses Computerized Adaptive Testing (CAT), gives you 2 hours, and presents 100 to 125 items. The passing score is 700 out of 1000 on a scaled, compensatory model (your total performance passes you, not each domain). The exam fee is USD 199, plus a USD 50 Annual Maintenance Fee (AMF) once you certify.

Domain weights are Security Principles 26%, Business Continuity/DR/Incident Response 10%, Access Controls 22%, Network Security 24%, and Security Operations 18%.

What a Configuration Baseline Contains

A configuration baseline is the approved secure starting point: it states exactly how a workstation, server, cloud instance, router, firewall, application, or database should be configured. Without a baseline, every build is a one-off and security depends on whoever installed it that day.

A strong baseline is specific enough to verify. "Secure the server" is not a baseline. "Disable SSH password login, allow SSH only from the management subnet, enable the host firewall, ship logs to the central collector, and apply the current approved patch group" is. Typical baseline items:

Baselines should be documented, versioned, approved, and reviewed as threats, business needs, and technology change.

Secure Defaults, Drift, and Validation

Secure defaults are protective settings applied before anyone customizes a system. Vendor defaults favor easy setup: a device may ship with a default password, unnecessary services, open management interfaces, weak example certificates, or permissive file sharing. Hardening changes those before production exposure. A new wireless controller, for example, should not deploy with the vendor admin password, management open from every VLAN, and legacy protocols enabled — you change credentials, restrict management to an admin network, enable secure protocols, disable old ones, and export logs.

Configuration drift is when a live system moves away from its baseline: a technician opens a temporary firewall rule and forgets it, a developer leaves a debug endpoint on, a host misses a policy update. Validation detects drift using endpoint management tools, configuration management, vulnerability scanners, cloud policy checks, or review — the goal is to find differences before attackers do.

Worked scenario

A team builds ten web servers by hand: five have host firewalls, three keep old test accounts, two send no logs. The deeper problem is the missing repeatable baseline and validation, not just the individual gaps. The fix: a hardened gold image, configuration management, a deployment checklist, and documented exceptions that are approved, monitored, and reviewed — otherwise exceptions silently become the new standard.

Common exam traps

• Choosing "install antivirus" when the scenario actually needs a repeatable, approved baseline.
• Confusing a secure default (a pre-configured setting) with validation (confirming the state held).
• Treating an undocumented exception as acceptable because "it works."

Where Baselines Come From and How They Are Maintained

Mature organizations rarely invent baselines from a blank page. They start from an authoritative benchmark and then tailor it to their environment. Widely used sources include the Center for Internet Security (CIS) Benchmarks, the U.S. Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs), and vendor hardening guides for a specific operating system or appliance.

CIS Benchmarks even define tiered profiles: Level 1 settings are safe for most environments with minimal functional impact, while Level 2 settings are stricter and intended for high-security contexts where some convenience is sacrificed. A team typically adopts a profile, removes settings that break required applications (documenting each exception), and freezes the result as the organization's approved baseline.

Once approved, a baseline becomes a living artifact. It must be versioned so you can answer "what was the approved state on the day this server was built?" It must have an owner who reviews it on a schedule and after major events: a new OS release, a new threat, a regulatory change, or a serious incident. Version control also lets you trace why a setting exists, which prevents a future engineer from "cleaning up" a control that was added deliberately.

Baselines and imaging

The practical delivery mechanism for a baseline is a gold image (a master template a build is cloned from) plus configuration management tooling that re-applies the baseline continuously. Imaging gives a consistent starting point; configuration management fights drift by re-asserting the desired state on a schedule. Together they turn "hope the technician remembered" into "the platform guarantees it." When a CC scenario describes inconsistent manual builds, the strongest answer almost always combines a hardened image, configuration management, and validation, not a single tool.

Tie to least functionality

A baseline is the written expression of least functionality: enable only the roles, services, ports, and accounts the business genuinely needs, and turn everything else off by default. That makes monitoring easier (less normal noise), shrinks the attack surface, and means any unexpected open port or running service is immediately suspicious. The exam frequently frames this as "which option best reduces risk before the system is exposed" — and the answer is the documented, least-functionality baseline applied as a secure default, then validated after deployment.