15.1 Configuration Baselines and Secure Defaults

Key Takeaways

  • A configuration baseline defines the approved secure starting point for systems, applications, and devices.
  • Secure defaults reduce risk by disabling unnecessary access, changing vendor defaults, and enabling protective settings before production use.
  • Baselines should be documented, versioned, approved, and reviewed as threats, business needs, and technology change.
  • Configuration drift occurs when systems move away from the approved baseline over time.
  • Baseline validation helps confirm that deployed systems match the intended hardened state.
Last updated: April 2026

Configuration Baselines and Secure Defaults

System hardening is the practice of reducing attack surface and making systems safer before and during operation. A configuration baseline is the approved secure starting point. It says how a workstation, server, cloud instance, router, firewall, application, or database should be configured. Without a baseline, every build becomes a one-off decision and security depends on whoever installed the system that day.

The current ISC2 CC outline is effective October 1, 2025, with a new outline effective September 1, 2026. The current exam is CAT, allows 2 hours, includes 100 to 125 items, and uses a 700 out of 1000 passing grade. The domain weights are 26, 10, 22, 24, and 18 percent, with Domain 5 weighted 18 percent. No public pass-rate claim is needed for study or exam decisions.

What a Baseline Contains

A baseline may include operating system version, approved services, local account settings, password or authentication settings, logging, time synchronization, firewall rules, endpoint protection, encryption, screen lock settings, remote access rules, browser settings, audit policy, and patch level. For a network device, it may include management protocols, allowed admin networks, SNMP settings, banner requirements, logging destination, disabled unused interfaces, and secure routing or switching options.

The baseline should be specific enough to verify. "Secure the server" is not a useful baseline. "Disable password login for SSH, allow SSH only from the management subnet, enable host firewall, send logs to the central collector, and apply the current approved patch group" is actionable.

Secure Defaults

Secure defaults are settings that reduce risk before anyone customizes the system. Vendor defaults often prioritize ease of setup. A device may ship with a default password, unnecessary services, open management interfaces, weak example certificates, or permissive sharing. Hardening changes those defaults before production exposure.

For example, a new wireless controller should not be deployed with the vendor default administrator password, open management from every VLAN, and unused services enabled. A hardened setup changes default credentials, limits management to an admin network, enables secure management protocols, disables old protocols, exports logs, and documents the approved configuration.

Drift and Validation

Configuration drift happens when deployed systems move away from the baseline. A technician opens a temporary firewall rule and forgets to close it. A developer enables a debug endpoint for troubleshooting. A server misses a policy update. Over months, the environment becomes inconsistent and harder to defend.

Validation checks whether systems still match the baseline. It can use endpoint management tools, configuration management, vulnerability scanners, cloud policy checks, scripts, or manual review. The point is not to punish administrators; it is to find differences before attackers use them.

Scenario Reasoning

A company builds ten new web servers manually. Five have host firewalls enabled, three have old test accounts, and two send no logs. The risk is not only the missing controls. The deeper problem is lack of a repeatable baseline and validation process. A better approach uses a hardened image, configuration management, documented exceptions, and a deployment checklist.

Baselines should also support change. If a business application truly needs an exception, the exception should be approved, documented, monitored, and reviewed. Otherwise, exceptions silently become the new standard. On the CC exam, choose baselines and secure defaults when the scenario asks for a consistent, approved, repeatable hardening state. Choose validation when the question asks how to confirm systems still match that state.

High-Yield Checkpoints

  • A configuration baseline defines the approved secure starting point for systems, applications, and devices.
  • Secure defaults reduce risk by disabling unnecessary access, changing vendor defaults, and enabling protective settings before production use.
  • Baselines should be documented, versioned, approved, and reviewed as threats, business needs, and technology change.
  • Configuration drift occurs when systems move away from the approved baseline over time.
  • Baseline validation helps confirm that deployed systems match the intended hardened state.
Test Your Knowledge

What is the main purpose of a configuration baseline?

A
B
C
D
Test Your Knowledge

Which example best represents configuration drift?

A
B
C
D
Test Your Knowledge

Which action is part of applying secure defaults to a new network device?

A
B
C
D