7.3 Configuration Management

Key Takeaways

CISSP 7.3 focuses on performing Configuration Management.

The current CISSP Exam Outline specifically gives provisioning, baselining and automation as examples.

Configuration Management establishes and maintains control over the state of systems throughout their lifecycle.

Configuration applies to hardware, firmware, operating systems, applications, networks, cloud services and other system components.

Secure technology can still become insecure through poor configuration.

A useful Configuration Management model is:

Define → Deploy → Monitor → Compare → Correct.

Desired state represents how a system should be configured.

Actual state represents how the running system is currently configured.

Configuration Management compares those two states and manages differences.

A Configuration Item - CI - is a component or group of components managed as one entity within the Configuration Management process.

Configuration information may be maintained in a CMDB or another configuration repository.

Configuration relationships can help identify dependencies between applications, databases, infrastructure and business services.

Asset inventory and Configuration Management are related but not identical.

Asset inventory primarily answers: What do we have?

Configuration Management additionally asks: How should it be configured and what state is it currently in?

Secure provisioning creates systems using an approved configuration from the beginning of their operational life.

Standard images and templates can make secure deployment faster and more consistent.

Build → harden → validate → register.

A golden image is not permanently secure.

Standard images must be maintained as vulnerabilities, technology and security requirements change.

A configuration baseline represents the formally established approved configuration used as a reference for future builds, changes and comparison.

Vendor defaults should not automatically be treated as an organisation's security baseline.

Default = how the vendor shipped it. Baseline = how the organisation approved it.

A configuration baseline and a security-control baseline are different.

A security-control baseline identifies safeguards that should apply.

A configuration baseline describes the approved configuration state.

System hardening reduces attack surface by removing unnecessary functionality and configuring required functionality securely.

Least functionality means systems should expose only functionality necessary for their purpose.

If the system does not need it, consider removing or disabling it.

Baselines can be standardised while still being tailored to different system purposes.

A workstation, database server and network appliance may legitimately require different secure configurations.

Configuration drift occurs when actual system configuration diverges from the approved or intended configuration.

Drift can arise from troubleshooting, manual administration, software installation, authorised change, automation failure or malicious activity.

Expected state vs actual state = detect drift.

Not every configuration difference is malicious.

A difference may represent an approved change or formal exception.

Conversely, unexplained configuration changes may indicate mistakes or attacker activity.

Automated Configuration Management can apply approved settings repeatedly and consistently across large environments.

Automation can support provisioning, configuration enforcement, policy checking, compliance monitoring and remediation.

Automation improves consistency. Automation does not guarantee correctness.

An insecure automated template can reproduce the same weakness across thousands of resources.

Infrastructure as Code represents infrastructure and configuration in machine-readable definitions.

Version control can provide history, review, accountability and rollback information for configuration definitions.

Infrastructure and configuration code should be reviewed and tested because of the impact it can have on production systems.

Sensitive credentials should not be unnecessarily stored inside configuration repositories.

Configuration code belongs in version control. Secrets belong in appropriate secret-management systems.

Mutable infrastructure modifies existing systems.

Immutable infrastructure commonly replaces existing workloads with newly built versions containing the updated approved state.

Policy as Code can automatically evaluate infrastructure against machine-readable security requirements.

Preventing insecure configuration before deployment is often preferable to discovering it after exposure.

Preventive configuration controls can block inappropriate states.

Detective configuration controls identify deviations that already exist.

Automated remediation can return systems to an approved state, but automatic correction should account for legitimate changes, exceptions and incident conditions.

Configuration Management and Change Management work together but answer different questions.

Configuration Management = What state should the system be in?

Change Management = How do we control movement from one state to another?

Once an approved change becomes the accepted production state, configuration records and baselines may need updating.

Patch Management is also related but narrower than Configuration Management.

Patches change software or firmware state, while Configuration Management covers the broader configuration of the system.

Important system configurations should be recoverable where necessary.

Known-good configuration backups can assist restoration after corruption, failure or inappropriate change.

Backup exists ≠ configuration is known good.

Configuration Monitoring can identify unexpected changes to services, permissions, logging, network settings and security controls.

File Integrity Monitoring can detect changes to important files but does not itself establish whether those changes were malicious.

Configuration exceptions should be formally documented rather than being allowed to become invisible drift.

Configuration-management interfaces and repositories should be protected with strong access control because modifying configuration can provide substantial control over systems.

Separation of duties may be appropriate for high-risk configuration activities.

Production configuration should reflect production security requirements.

Development features such as debugging and verbose errors may be inappropriate in production.

Configuration testing is most meaningful when the test environment sufficiently represents the relevant production environment.

Baselines require review and maintenance.

Baseline = controlled reference. Baseline ≠ frozen forever.

Cloud environments increase the importance of automated Configuration Management because resources can be provisioned rapidly and at large scale.

Cloud configuration areas include IAM, network controls, storage permissions, encryption, logging and service configuration.

Customer-controlled cloud configuration remains the customer's responsibility even when the cloud provider secures underlying infrastructure.

Containers and other ephemeral systems make it useful to control the images and deployment definitions that repeatedly create workloads rather than depending on manual configuration of each instance.

When thousands of temporary systems come from the same template, secure the template.

Configuration deviation can itself provide valuable security telemetry.

A security control suddenly being disabled may represent an operational mistake or evidence of attack and should be evaluated in context.

The central CISSP principle is: know what the secure configuration should be, deploy it consistently, control legitimate changes, detect unexpected differences and maintain a trustworthy configuration state throughout the system lifecycle.