SkarpSkarp

Chapter 4 of 27

Change Management and Secure Configuration Practices

Peek behind the scenes of how secure organizations introduce changes without breaking systems or opening new attack paths, from formal change requests to configuration baselines.

27 min readen

Why Change Management Matters for Security

Change and Security

Most outages and many breaches involve a change: a rushed patch, a bad firewall rule, a new app. Change management exists to make changes safer, more predictable, and auditable.

Link to CIA and GRC

Change management is an administrative control that protects availability, integrity, and confidentiality, and it supports governance, risk, and compliance expectations.

Zero Trust Mindset

Zero trust says "no implicit trust" for users and devices. Change management applies the same idea to systems: no unverified, undocumented, or unlimited changes.

Key Question

For every change, ask: "If this goes badly, how could it impact confidentiality, integrity, or availability?" That question drives secure change decisions.

The Change Management Lifecycle: From Idea to Closure

Lifecycle Overview

The change management lifecycle is a repeatable path from idea to closure: request, review, risk assessment, approval, implementation, validation, and closure.

Request and Review

A Request for Change (RFC) describes the change and its impact. The change is classified (standard, normal, emergency) and may be sent to a Change Advisory Board.

Risk and Approval

Teams assess technical and security risks, plan implementation and rollback, then obtain approvals. Separation of duties means implementers are not the only approvers.

Implementation to Closure

Changes are implemented in a controlled window, validated with testing and monitoring, then documented and closed. Baselines and docs are updated to reflect the new normal.

Walkthrough: Patching a Public Web Server

The Scenario

A critical remote code execution bug is found in a public web server. The system owner opens an RFC to apply the vendor patch to the web server cluster.

Review and Risk

The change is classified as a normal, high-priority security change. Risks of patching vs not patching are assessed, and staging tests plus a rollback plan are defined.

Approval and Implementation

Multiple roles approve the change. Ops patch servers one by one in a maintenance window, monitor logs and metrics, and keep snapshots ready for rollback.

Validation and Closure

Teams test key user flows, confirm WAF rules and scanner results, then update the change record and baseline configuration to reflect the new patch level.

Secure Configuration Baselines: The "Known Good" State

What is a Baseline?

A secure configuration baseline is a documented, approved set of configuration settings that defines the "known good" state for a system or system type.

Baseline Examples

Examples include OS baselines (BitLocker, firewall rules) and database baselines (TLS version, logging, encryption) aligned with internal policy and industry guidance.

Why Baselines Matter

Baselines give consistency, auditability, and speed. You can compare systems to the baseline, deploy new ones quickly, and rebuild or verify after incidents.

Baselines as Changes

Changing a baseline affects many systems and must go through formal change management. On exams, look for "secure baselines" as the best-practice answer.

Configuration Management Tools and CMDBs

Config Management Tools

Configuration management tools describe desired system states in code: packages, services, configs, permissions, and firewall rules are all defined and enforced.

Infrastructure as Code

This approach, called infrastructure as code, lets tools repeatedly apply the desired state and correct drift, reducing risky, undocumented manual tweaks.

What is a CMDB?

A Configuration Management Database (CMDB) tracks configuration items like servers, apps, and network devices, plus their relationships and change history.

Security Benefits

Together, config tools and CMDBs give visibility, consistency, and traceability, helping you know what you have and how changes affect security.

Thought Exercise: Spot the Risky Change

Read the scenario and answer the prompts mentally or in notes.

Scenario

A developer has trouble connecting from a new microservice in the cloud to an on-prem database. To "unblock" testing, they:

  • Log into the firewall with their admin account.
  • Add a rule allowing `ANY` source to connect to the database on TCP 1433.
  • Do not create a change ticket because "it is just temporary".
  • Plan to remove the rule later but do not document that plan.

Questions to think through

  1. Which steps of the formal change management lifecycle were skipped here?
  2. List at least three security risks this creates (think confidentiality, integrity, availability).
  3. How could secure configuration baselines and tools have helped here?
  4. If you were the security analyst who discovered this rule, what actions would you take next?

Suggested answers (compare after you think)

  1. Skipped steps: formal Request, Review/Classification, Risk Assessment and Planning, Approval, and likely proper Validation and Closure.
  2. Risks:
  • Exposes the database to the entire internet or large networks (confidentiality risk).
  • Increases chance of SQL injection or brute-force attacks (integrity and confidentiality).
  • Potential DoS against the database (availability).
  • No audit trail or accountability for the change.
  1. Baselines/tools:
  • A firewall baseline could prohibit `ANY` rules and flag them as non-compliant.
  • Configuration management could automatically revert unauthorized rules.
  1. Possible actions:
  • Immediately assess exposure and tighten the rule to least privilege.
  • Open an incident and a formal change to correct the configuration.
  • Educate the team and possibly adjust processes so developers cannot bypass change management so easily.

Separation of Duties, Approvals, and Emergency Changes

Separation of Duties

Separation of duties means no single person controls a sensitive change end-to-end. Requesters, approvers, and implementers should be distinct roles when risk is high.

Approvals

Approvals come from technical, business, and security stakeholders. This prevents both malicious and well-intentioned but risky unilateral changes.

Emergency Changes

In emergencies, processes are streamlined but not removed: rapid approvals, quick implementation, then a post-change review and full documentation afterward.

Exam Angle

If an admin makes major changes alone, the likely Security+ fix is to enforce formal approvals and separation of duties, even for urgent work.

Rollback and Back-out Plans: Planning for Failure

Why Rollback Matters

Rollback or back-out plans define how to restore systems to a known-good state when a change goes wrong. Secure processes assume some changes will fail.

Plan Contents

Good plans define triggers, concrete steps, time limits, and data considerations. They do more than say "undo the change".

Security Benefits

Rollback plans help avoid leaving broken security controls disabled and give a safe exit if a new configuration unexpectedly weakens defenses.

Exam Tip

If a scenario shows a failed change causing outages with no easy recovery, the missing control is often a tested rollback or back-out plan.

Change-Related Risk Assessment: Thinking Like an Attacker

Purpose of Risk Assessment

Change-related risk assessment estimates how a change could impact confidentiality, integrity, availability, and the overall attack surface.

Key Questions

Ask what assets and data are affected, how the attack surface changes, what could go wrong technically, and what compensating controls you need.

Security-Focused Answers

Good answers highlight security impact, apply least privilege and defense in depth, and include testing and monitoring in the change plan.

Hidden Impacts

Even performance or usability tweaks can open new ports, roles, or integrations that introduce serious security risk if not assessed.

Quiz 1: Core Concepts Check

Test your understanding of change management fundamentals.

Which option BEST explains why secure configuration baselines are important in change management?

  1. They eliminate the need for formal approvals because systems are already secure.
  2. They define a known good state that changes can be compared against and restored to.
  3. They allow developers to bypass the CAB when urgent fixes are needed.
  4. They replace the need for logging and monitoring during changes.
Show Answer

Answer: B) They define a known good state that changes can be compared against and restored to.

Baselines define the approved, known good configuration. During and after changes, you can compare current settings to the baseline to detect drift and, if needed, restore systems. They do not remove the need for approvals, CABs, or monitoring.

Quiz 2: Applying Separation of Duties

Apply separation of duties and approvals to a scenario.

An administrator submits a change to open a new inbound port on the perimeter firewall for a third-party vendor. Which control MOST directly enforces separation of duties in this situation?

  1. Require the same administrator to document and approve the change before implementing it.
  2. Require approval from the system owner and security team before the administrator implements the change.
  3. Allow the administrator to implement the change during a maintenance window without a ticket.
  4. Automatically approve all firewall changes that include business justifications.
Show Answer

Answer: B) Require approval from the system owner and security team before the administrator implements the change.

Separation of duties means the implementer should not be the sole approver. Requiring approval from the system owner and security team ensures multiple roles review and authorize the firewall change.

Key Term Flashcards: Change and Configuration

Flip through these cards (mentally or in notes) and see if you can recall each definition before revealing it.

Change management lifecycle
A structured sequence of steps (request, review/classification, risk assessment and planning, approval, implementation, validation, closure) used to introduce changes in a controlled, auditable, and low-risk way.
Request for Change (RFC)
The formal record or ticket that initiates a change, describing what will be changed, why, affected systems, risk/impact, timing, and implementation details.
Change Advisory Board (CAB)
A cross-functional group (e.g., operations, security, business owners) that reviews and approves or rejects significant changes based on risk and business impact.
Secure configuration baseline
A documented, approved set of configuration settings that defines the known good, secure state for a system or group of systems.
Configuration management tool
Software that defines and enforces desired system configurations (infrastructure as code), helping keep systems consistent with secure baselines and correcting drift.
Configuration Management Database (CMDB)
A centralized repository that tracks configuration items (CIs) such as servers, applications, and network devices, along with their attributes, relationships, and change history.
Separation of duties (SoD) in change management
A control that ensures no single person can request, approve, and implement a high-risk change alone, reducing the risk of malicious or unchecked actions.
Rollback / back-out plan
A predefined, tested set of steps to restore systems to their previous known-good state if a change causes issues or unexpected risk.
Emergency change
A high-urgency change made to address an immediate incident or critical issue, using a streamlined but still documented and approved process with post-change review.
Change-related risk assessment
The process of analyzing how a proposed change might impact confidentiality, integrity, availability, and the attack surface, and identifying necessary compensating controls.

Mini Case Study: Evaluating a Proposed Change

Use this mini case to practice evaluating security impacts and compensating controls.

Scenario

Your company plans to integrate a new third-party analytics service. To do this, a change is proposed:

  • Customer data from the production database will be exported daily to the vendor’s cloud platform.
  • A new outbound firewall rule will allow the database server to connect to the vendor’s API over HTTPS.
  • The vendor will access the data to generate usage reports.

Your tasks

  1. Identify at least three security risks associated with this change.
  2. Suggest at least three security controls or requirements you would include in the change plan.
  3. Decide what type of approvals are needed before implementation.

Pause and think, then compare with the sample reasoning below.

Sample reasoning

  1. Risks:
  • Confidentiality: Customer data leaves your environment; risk of vendor breach or misuse.
  • Integrity: Data could be altered in transit or by the vendor, affecting reports.
  • Compliance: Data protection laws or contracts may restrict cross-border transfers.
  • Attack surface: New outbound rule from a sensitive database host; potential exfiltration path.
  1. Controls:
  • Data minimization and masking; send only required fields, pseudonymize if possible.
  • Strong encryption in transit (TLS), plus encryption at rest on the vendor side.
  • Vendor due diligence and a security/privacy addendum in the contract.
  • Egress firewall rules restricted to specific IPs/URLs and ports; no general internet access from the database.
  • Monitoring and alerting on unusual export volumes or destinations.
  1. Approvals:
  • System/data owner (business owner of customer data).
  • Security team (to review controls and vendor posture).
  • Legal/compliance (if regulated data is involved).

This is the type of reasoning Security+ expects when it asks you to evaluate a change for security impact.

Key Terms

Emergency change
A high-urgency change made to address an immediate incident or critical issue, using a streamlined but still documented and approved process with post-change review.
Request for Change (RFC)
The formal record or ticket that initiates a change, describing what will be changed, why, affected systems, risk/impact, timing, and implementation details.
Rollback / back-out plan
A predefined, tested set of steps to restore systems to their previous known-good state if a change causes issues or unexpected risk.
Separation of duties (SoD)
A control that ensures no single person can perform all critical steps of a sensitive process end-to-end, reducing the risk of fraud, abuse, or unchecked mistakes.
Change Advisory Board (CAB)
A cross-functional group (e.g., operations, security, business owners) that reviews and approves or rejects significant changes based on risk and business impact.
Change management lifecycle
A structured sequence of steps (request, review/classification, risk assessment and planning, approval, implementation, validation, closure) used to introduce changes in a controlled, auditable, and low-risk way.
Configuration management tool
Software that defines and enforces desired system configurations (infrastructure as code), helping keep systems consistent with secure baselines and correcting drift.
Secure configuration baseline
A documented, approved set of configuration settings that defines the known good, secure state for a system or group of systems.
Change-related risk assessment
The process of analyzing how a proposed change might impact confidentiality, integrity, availability, and the attack surface, and identifying necessary compensating controls.
Configuration Management Database (CMDB)
A centralized repository that tracks configuration items (CIs) such as servers, applications, and network devices, along with their attributes, relationships, and change history.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself