Configuration Management

When You Cannot Answer “What Changed?”

A production web server goes down at 11:00 PM on a Friday. The operations team spends three hours troubleshooting before discovering that someone modified the firewall rules earlier that day. Nobody recorded the change. Nobody approved it. The person who made it left for vacation. Without configuration management, the question “what changed?” has no answer, and every troubleshooting effort starts from scratch.

Configuration management answers three questions that matter during every incident, every audit, and every change: What is the approved state? What is the current state? What is different between them?

This module covers CISSP exam objective 7.3: perform configuration management. The exam tests whether you understand configuration management as a governance discipline — establishing baselines, controlling changes, detecting drift, and maintaining an accurate record of what is running in your environment.

Configuration Baselines

A configuration baseline is the documented, approved state of a system at a specific point in time. It defines exactly what software is installed, what services are running, what ports are open, what security settings are applied, and what patches are current.

Baselines serve two purposes:

• Provisioning standard — New systems are built to the baseline specification. This ensures every server, workstation, or network device starts from a known, approved, hardened state.
• Comparison reference — The current state of any system can be compared against its baseline to identify unauthorized changes, missing patches, or configuration drift.

A baseline is not a one-time document. It must be updated through the change management process whenever an approved change modifies the standard configuration. An outdated baseline is worse than no baseline — it creates a false sense of control while the actual environment diverges.

Configuration Management Database (CMDB)

The CMDB is the central repository that records configuration items (CIs) and the relationships between them. A CI is any component that needs to be managed to deliver an IT service: servers, applications, network devices, databases, licenses, and documentation.

For each CI, the CMDB records:

• Identification — Unique identifier, name, version, location
• Classification — Type, category, criticality level
• Ownership — Asset owner, custodian, support team
• Configuration state — Current settings, installed software, applied patches
• Relationships — Dependencies, parent/child connections, service mappings
• Change history — Record of all approved changes with dates and approvers

The CMDB’s value becomes clear during incident response. When a vulnerability is announced for a specific software version, the CMDB identifies every affected system. When a server fails, the CMDB shows what depends on it. When an unauthorized change is detected, the CMDB shows the approved state for comparison.

Asset Inventory and Configuration Item Identification

You cannot manage what you have not identified. Configuration management begins with a complete asset inventory that feeds the CMDB.

Asset discovery uses multiple methods:

• Network scanning — Automated discovery of devices connected to the network
• Agent-based inventory — Software agents on endpoints that report hardware, software, and configuration details
• Cloud API integration — Querying cloud provider APIs to discover virtual machines, containers, storage accounts, and services
• Manual registration — Devices that cannot be automatically discovered (air-gapped systems, OT equipment) must be manually registered

The scope of CIs must be defined. Not everything needs individual tracking in the CMDB. A general rule: if a change to the item could affect a service or create a security risk, it should be a tracked CI. Keyboards do not need CMDB entries. Firewall rule sets do.

Change Control Boards

A Change Advisory Board (CAB) or Change Control Board (CCB) is the governance body that reviews and approves changes to the configuration baseline. The CAB typically includes representatives from security, operations, development, and the business units affected by the change.

The change management process for configuration changes follows a standard flow:

1. Request — A change request (RFC) is submitted describing the change, its purpose, the systems affected, and a rollback plan
2. Review — The CAB evaluates the risk, impact, and timing of the change. Security reviews assess whether the change introduces vulnerabilities or violates policy.
3. Approve or reject — The CAB makes a decision. Emergency changes may follow an expedited process but must still be documented and reviewed after implementation.
4. Implement — The change is made during an approved window, following the documented procedure
5. Verify — The change is tested to confirm it achieved the desired outcome without introducing problems
6. Document — The CMDB is updated to reflect the new configuration state

Emergency changes bypass normal review timelines but must not bypass documentation and post-implementation review. An emergency change that is never reviewed retroactively is an uncontrolled change with a convenient label.

Configuration Auditing

Configuration auditing compares the actual state of systems against their approved baselines. The goal is to detect configuration drift — the gradual, often unnoticed divergence between what is approved and what is actually running.

Configuration audits answer:

• Are systems configured according to their baselines?
• Have unauthorized changes been made?
• Are required security settings still in place?
• Is the CMDB accurate and current?

Automated tools perform configuration audits continuously, scanning systems and comparing their settings against policy templates. Manual audits supplement automated checks for areas that tools cannot reach — process compliance, documentation accuracy, and physical configuration.

Secure Baseline Images and Hardening

A secure baseline image (golden image) is a pre-configured system template that incorporates security hardening before deployment. Instead of deploying a default operating system and then hardening it, you deploy a system that is already hardened.

Hardening a baseline image includes:

• Removing unnecessary services, protocols, and software
• Applying current security patches
• Configuring access controls and authentication settings
• Enabling logging and forwarding to the centralized SIEM
• Disabling default accounts and changing default credentials
• Applying CIS Benchmarks, DISA STIGs, or organizational hardening standards

Golden images must be maintained. When a new patch or security configuration change is required, the golden image is updated so that all future deployments include the change. Existing systems deployed from the old image must be updated separately — the golden image only affects new deployments.

Drift Detection and Automated Configuration Management

Configuration drift is inevitable in any environment where humans interact with systems. An administrator makes a quick fix at 2:00 AM during an outage. A developer changes a setting to test something and forgets to revert it. A patch modifies a configuration file. Over time, systems that started identical drift apart.

Automated configuration management tools address drift in two ways:

• Detection — Continuously comparing system state against the approved baseline and alerting when differences are found
• Remediation — Automatically reverting unauthorized changes to bring systems back to the baseline state

Tools like Puppet, Chef, Ansible, and SaltStack define system configurations as code and enforce them continuously. If someone manually changes a setting, the tool detects the drift and restores the approved configuration on its next run.

Infrastructure as Code from an Operations Perspective

Infrastructure as Code (IaC) extends configuration management by defining entire environments — servers, networks, storage, security groups — in version-controlled code files. From a security operations standpoint, IaC provides:

• Auditability — Every infrastructure change is a code commit with a timestamp, author, and review trail
• Repeatability — Environments can be rebuilt identically from code, eliminating manual configuration errors
• Drift prevention — If the running environment does not match the code definition, it can be automatically reconciled
• Disaster recovery — Infrastructure can be recreated from code rather than manual rebuild procedures

Pattern Recognition

Configuration management questions on the CISSP follow these structures:

• Unknown change caused an incident — The root cause is a change management or configuration control failure. The answer involves establishing or enforcing change control processes.
• Systems are inconsistently configured — Configuration drift. The answer involves baseline enforcement, automated configuration management, or drift detection.
• Vulnerability affects unknown systems — The CMDB is incomplete or inaccurate. The answer involves improving asset inventory and configuration tracking.
• Emergency change bypassed process — Emergency changes are allowed but must be documented and reviewed retroactively.

Trap Patterns

Watch for these wrong answers:

• “Prevent all changes to avoid configuration drift” — Change is necessary. The goal is controlled change, not no change.
• “The golden image eliminates the need for patching” — Golden images provide a secure starting point. Systems deployed from them still require ongoing patching and configuration updates.
• “The CMDB replaces vulnerability scanning” — The CMDB records what is deployed. Vulnerability scanning identifies what is vulnerable. They are complementary, not interchangeable.
• “Configuration management is only for servers” — CM applies to any managed component: network devices, applications, cloud resources, security tools, and more.

Scenario Practice

Question 1

A security audit reveals that 40% of production servers have configurations that differ from the approved baseline. The differences include disabled logging, modified firewall rules, and additional software packages. The operations team states that changes were made during incident response and troubleshooting over the past year.

What is the BEST corrective action?

A. Reimage all 40% of servers from the current golden image immediately
B. Document the current state as the new baseline since the changes were made by authorized personnel
C. Implement automated configuration management to detect drift and enforce baselines, with a remediation plan for existing deviations
D. Restrict operations team access so they cannot modify server configurations

Question 2

A company uses infrastructure as code to manage its cloud environment. A developer commits a change that opens port 22 (SSH) to the public internet on a production security group. The change passes automated testing and is deployed. Two days later, the security team discovers the exposure during a routine scan.

What control should have prevented this?

A. Manual security review of all infrastructure code changes before deployment
B. Security policy checks integrated into the IaC deployment pipeline that block non-compliant configurations
C. Daily vulnerability scanning of all cloud resources
D. Restricting IaC deployment permissions to the security team only

Question 3

An organization’s CMDB shows 200 servers in its data center. A network discovery scan identifies 215 IP addresses responding to probes. The 15 additional devices are not registered in the CMDB.

What is the FIRST step to address this finding?

A. Block network access for the 15 unregistered devices immediately
B. Identify and classify the 15 devices, determine their purpose and owner, and register them in the CMDB or initiate decommissioning
C. Update the CMDB to include the 15 devices based on the scan results alone
D. Assume the devices are test systems and exclude them from future scans

Key Takeaway

Configuration management is the discipline of knowing what you have, knowing how it should be configured, and detecting when reality no longer matches the plan. On the exam, remember this sequence: baseline (define the approved state), control (manage changes through a formal process), monitor (detect drift from the baseline), and remediate (bring systems back into compliance). Every configuration management question maps to a failure in one of these four steps.