Lesson Twenty-Five

Configuration Management, Resource Protection, Patch Management, and Change Control

SierraTec Secure CISSP Certification Preparation Course

Lesson Overview

Secure systems do not remain secure automatically.

A server can begin its operational life with:

• a hardened operating system;

• approved firewall rules;

• strong authentication;

• current patches;

• unnecessary services disabled;

• appropriate logging enabled.

Six months later, administrators may have:

• installed temporary software;

• changed firewall rules;

• enabled troubleshooting services;

• postponed patches;

• created undocumented accounts;

• modified encryption settings.

The system may still be running.

But it may no longer represent:

the secure state management originally approved.

This is why security operations requires disciplined configuration management, resource protection, patch management, and change management.

The core operational problem is:

KNOWN SECURE STATE

       │

       ▼

OPERATIONAL CHANGE

       │

       ▼

AUTHORIZED?

       │

       ▼

TESTED?

       │

       ▼

SECURE?

       │

       ▼

DOCUMENTED?

       │

       ▼

VERIFIED?

The current CISSP Examination Outline places this lesson primarily under four Domain 7 objectives:

7.3 — Perform Configuration Management

ISC2 gives examples of:

• provisioning;

• baselining;

• automation.

7.5 — Apply Resource Protection

Including:

• media management;

• media protection techniques;

• data at rest;

• data in transit.

7.8 — Implement and support patch and vulnerability management

7.9 — Understand and participate in change management processes.

These objectives should not be studied independently.

They form an operational control chain:

CONFIGURE SECURELY

       ↓

PROTECT RESOURCES

       ↓

PATCH WEAKNESSES

       ↓

CONTROL CHANGES

       ↓

VERIFY STATE

       ↓

MONITOR DRIFT

NIST SP 800-128 describes security-focused configuration management as managing and monitoring system configurations to achieve adequate security while minimizing organizational risk and supporting required business functionality.

For patching, NIST SP 800-40 Rev. 4 defines enterprise patch management around identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades, and frames patching as a form of preventive maintenance.

For media sanitization, the current NIST publication is SP 800-88 Rev. 2, finalized September 26, 2025. It superseded Rev. 1 and emphasizes establishing an enterprise sanitization program based on information sensitivity and appropriate sanitization controls.

The central Lesson Twenty-Five question is:

How should organizations maintain secure and known system states while protecting information and media, applying security updates, and controlling operational changes without introducing unacceptable security, integrity, or availability risk?

CISSP Exam Objective Alignment

Learning Objectives

After completing this lesson, you should be able to:

1. Define configuration management.

2. Explain security-focused configuration management.

3. Define a configuration item.

4. Explain configuration inventory.

5. Define a configuration baseline.

6. Distinguish a baseline from a benchmark.

7. Explain secure provisioning.

8. Explain hardened builds.

9. Explain gold images.

10. Explain secure templates.

11. Explain configuration drift.

12. Explain configuration monitoring.

13. Explain unauthorized configuration changes.

14. Explain least functionality.

15. Explain automation in configuration management.

16. Explain Infrastructure as Code conceptually.

17. Explain configuration-as-code principles.

18. Explain version control for configuration.

19. Explain configuration rollback.

20. Explain Configuration Management Database concepts.

21. Define resource protection.

22. Explain media management.

23. Identify removable-media risks.

24. Explain media inventory and accountability.

25. Explain media labeling.

26. Explain media transport controls.

27. Explain media storage controls.

28. Explain data at rest.

29. Explain data in transit.

30. Explain encryption requirements conceptually.

31. Explain data remanence.

32. Define media sanitization.

33. Explain Clear.

34. Explain Purge.

35. Explain Destroy.

36. Explain cryptographic erase.

37. Distinguish sanitization from ordinary deletion.

38. Explain sanitization validation.

39. Explain media reuse.

40. Explain media disposal.

41. Explain patch management.

42. Describe the patch-management lifecycle.

43. Distinguish patch, update, and upgrade conceptually.

44. Explain patch identification.

45. Explain patch prioritization.

46. Explain risk-based patching.

47. Explain patch acquisition.

48. Explain patch testing.

49. Explain staged deployment.

50. Explain maintenance windows.

51. Explain emergency patching.

52. Explain rollback planning.

53. Explain patch verification.

54. Explain failed-patch handling.

55. Explain vulnerability-to-patch mapping.

56. Explain End of Life.

57. Explain End of Support.

58. Explain legacy-system risk.

59. Explain compensating controls for unpatchable systems.

60. Define change management.

61. Explain change requests.

62. Explain change-impact analysis.

63. Explain change authorization.

64. Explain standard, normal, and emergency change concepts.

65. Explain change scheduling.

66. Explain change testing.

67. Explain implementation planning.

68. Explain rollback/backout planning.

69. Explain post-implementation review.

70. Explain documentation updates.

71. Explain segregation of duties in change management.

72. Explain configuration verification after change.

73. Explain why security and availability must both be considered.

74. Explain unauthorized-change detection.

75. Apply CISSP reasoning to configuration, patch, and change scenarios.

Part I — Configuration Management

1. What Is Configuration Management?

Configuration management is the disciplined process used to:

• identify system configurations;

• establish approved states;

• control changes;

• document changes;

• monitor the resulting state.

The objective is not merely:

knowing what hardware exists.

It is also knowing:

how that hardware and software should be configured.

2. Configuration Is Security-Relevant

Configuration determines matters such as:

• which services run;

• which ports listen;

• which users have privileges;

• which encryption protocols are permitted;

• which logs are generated.

A configuration mistake can defeat an otherwise strong technology.

Part II — Security-Focused Configuration Management

3. SecCM

NIST SP 800-128 uses the term security-focused configuration management, or SecCM, to emphasize integrating security into configuration-management activities.

Its goal is to manage and monitor system configurations in ways that reduce organizational risk while still supporting required functionality.

4. Core Security Relationship

BUSINESS FUNCTION

      +

SECURITY REQUIREMENTS

      ↓

APPROVED CONFIGURATION

      ↓

CONTROLLED CHANGE

      ↓

MONITORING

Part III — Configuration Item

5. Configuration Item

A Configuration Item, or CI, is a component whose configuration requires management.

Examples may include:

• server;

• router;

• firewall;

• operating system;

• application;

• database;

• cloud resource;

• configuration file.

6. Why Identify CIs?

Because security teams must know:

What exactly is being managed?

Without clear configuration-item boundaries:

• ownership becomes unclear;

• changes are difficult to track;

• baselines are difficult to enforce.

Part IV — Configuration Inventory

7. Inventory

A configuration inventory should help establish:

• what exists;

• version;

• owner;

• environment;

• approved configuration state.

8. Asset Inventory vs Configuration Inventory

Asset inventory:

What assets exist?

Configuration inventory:

How are those assets configured?

Part V — Baseline Configuration

9. Baseline

NIST describes a baseline configuration as a documented set of specifications for a system or configuration item that has been formally reviewed and agreed upon and can thereafter be changed only through change-control procedures.

10. Baseline Purpose

The baseline answers:

What is the approved state?

11. Baseline Example

SERVER BASELINE



Operating System:

Approved Version



Firewall:

Enabled



Remote Administration:

Approved secure protocol only



Logging:

Enabled



Unused Services:

Disabled



Encryption:

Approved configuration

Part VI — Baseline Is Not Default Configuration

12. Important Distinction

Vendor default:

How the system ships.

Security baseline:

How the organization approves the system to operate.

These may be very different.

Part VII — Baseline Versus Benchmark

13. Benchmark

A security benchmark is generally a reference configuration or hardening recommendation.

A baseline is:

the organization's formally approved configuration state.

14. Relationship

EXTERNAL BENCHMARK

      +

ORG REQUIREMENTS

      +

RISK

      ↓

ORGANIZATIONAL BASELINE

Part VIII — Secure Provisioning

15. Provisioning

Provisioning creates or prepares systems for operational use.

Current CISSP Objective 7.3 explicitly identifies provisioning as a Configuration Management example.

16. Insecure Provisioning

Bad process:

INSTALL DEFAULT OS

      ↓

CONNECT TO INTERNET

      ↓

PATCH LATER

      ↓

HARDEN SOMEDAY

This creates unnecessary exposure.

17. Better Provisioning

APPROVED BUILD

      ↓

SECURE CONFIGURATION

      ↓

PATCH

      ↓

IDENTITY / ACCESS CONFIGURED

      ↓

LOGGING CONFIGURED

      ↓

VALIDATE

      ↓

DEPLOY

Part IX — Gold Image

18. Gold Image

A gold image is an approved system image used to deploy standardized systems.

Benefits:

• consistency;

• rapid deployment;

• reduced manual error.

19. Gold Image Risk

If the image contains:

• outdated patches;

• insecure software;

• embedded secrets;

every deployed system inherits the weakness.

Part X — Template Risk

20. One Bad Template, Many Bad Systems

INSECURE TEMPLATE

       │

 ┌─────┼─────┐

 ▼     ▼     ▼

S1     S2     S3

This is why root-cause remediation matters.

Part XI — Hardened Builds

21. Hardening

Hardening reduces unnecessary attack surface.

It may include:

• removing unnecessary services;

• disabling unused accounts;

• restricting administrative interfaces;

• applying secure protocol settings.

Part XII — Least Functionality

22. Principle

If a system does not require a capability:

consider disabling or removing it.

Every unnecessary service can increase:

attack surface.

Part XIII — Configuration Drift

23. Drift

Configuration drift occurs when the operational system gradually differs from the approved baseline.

24. Example

Approved:

REMOTE DESKTOP

Disabled

Six months later:

REMOTE DESKTOP

Enabled for troubleshooting

Never disabled

That is configuration drift.

Part XIV — Drift Causes

25. Common Causes

• troubleshooting changes;

• emergency fixes;

• manual administration;

• application installation;

• undocumented exceptions.

Part XV — Configuration Monitoring

26. Detect Drift

APPROVED BASELINE

       │

       ▼

COMPARE

       ▲

       │

CURRENT CONFIGURATION

       │

       ▼

DIFFERENCE?

    ┌──┴──┐

   NO    YES

         │

         ▼

     INVESTIGATE

Part XVI — Unauthorized Change

27. A Difference Is Not Automatically Malicious

The change could be:

• authorized;

• accidental;

• malicious.

The security question is:

Was it properly approved and documented?

Part XVII — Automation

28. Current CISSP Alignment

Automation is explicitly named as an example in Objective 7.3.

29. Automation Benefit

Instead of manually configuring 5,000 systems:

APPROVED POLICY

      ↓

AUTOMATION

      ↓

CONSISTENT CONFIGURATION

30. Automation Risk

Automation increases:

speed and scale.

That applies to mistakes too.

BAD CONFIGURATION

       ×

5,000 SYSTEMS

       =

LARGE INCIDENT

Part XVIII — Infrastructure as Code

31. IaC Concept

Infrastructure as Code represents infrastructure configuration through machine-readable definitions.

Benefits can include:

• repeatability;

• versioning;

• peer review;

• automation.

32. Security Advantage

Configuration becomes:

reviewable before deployment.

Part XIX — Configuration as Code

33. Example

Instead of manually setting firewall rules:

CODE / DECLARATIVE CONFIGURATION

          ↓

REVIEW

          ↓

APPROVAL

          ↓

AUTOMATED DEPLOYMENT

Part XX — Version Control

34. Why Version Configurations?

Version control can show:

• what changed;

• who changed it;

• when;

• previous approved state.

35. Rollback

If an approved configuration update causes serious problems:

a known previous version may support controlled rollback.

Part XXI — CMDB

36. Configuration Management Database

A CMDB conceptually stores information about managed configuration items and their relationships.

37. Relationship Matters

Example:

WEB APP

   ↓

APPLICATION SERVER

   ↓

DATABASE

   ↓

IDENTITY SERVICE

Changing one component may affect several others.

Part XXII — Dependency Mapping

38. Security Value

Understanding dependencies improves:

• change impact analysis;

• incident response;

• recovery;

• patch planning.

Part XXIII — Configuration Documentation

39. Documentation Should Match Reality

Bad situation:

Network diagram says Firewall A.

Reality:

Firewall B replaced it 18 months ago.

Stale documentation creates operational risk.

Part XXIV — Resource Protection

40. Objective 7.5

Current CISSP Objective 7.5 includes:

• media management;

• media protection techniques;

• data at rest;

• data in transit.

Part XXV — What Is Media?

41. Media

Media can include technologies that store or transport information.

Examples:

• hard drives;

• SSDs;

• USB drives;

• optical media;

• backup media;

• memory cards.

Part XXVI — Media Lifecycle

42.

ACQUIRE

  ↓

REGISTER

  ↓

USE

  ↓

STORE

  ↓

TRANSPORT

  ↓

REUSE

  ↓

SANITIZE

  ↓

DISPOSE

Part XXVII — Media Inventory

43. Why Track Media?

Sensitive removable media can:

• leave facilities;

• be lost;

• be stolen;

• retain data after use.

Part XXVIII — Media Ownership

44. Accountability

Organizations may record:

• identifier;

• owner/custodian;

• classification;

• location;

• disposition.

Part XXIX — Media Labeling

45. Labeling

Labels can help users recognize:

• sensitivity;

• handling requirements.

46. Labeling Risk

Physical labels can themselves expose sensitive information.

Example:

“TOP SECRET CUSTOMER KEYS”

on removable media may reveal too much.

Apply labeling according to policy.

Part XXX — Removable Media

47. Removable Media Risks

Removable media can introduce:

• malware;

• data leakage;

• unauthorized copying;

• loss.

Part XXXI — Removable Media Controls

48. Possible Controls

Organizations may:

• restrict use;

• approve devices;

• encrypt media;

• log connections;

• disable unnecessary interfaces.

The correct control depends on risk and operational need.

Part XXXII — Media Storage

49. Sensitive Media

Protect according to information sensitivity.

Controls may include:

• controlled rooms;

• cabinets;

• access restrictions;

• environmental protection.

Part XXXIII — Media Transport

50. Transport

When sensitive media moves:

AUTHORIZED CUSTODIAN

       ↓

PROTECTED MEDIA

       ↓

TRACKED TRANSFER

       ↓

AUTHORIZED RECIPIENT

Part XXXIV — Data at Rest

51. Definition

Data at rest is information stored rather than actively traversing a communications channel.

Examples:

• disk;

• database;

• backup;

• object storage.

Part XXXV — At-Rest Protection

52. Controls May Include

• access control;

• encryption;

• physical protection;

• key management.

Part XXXVI — Encryption Is Not Everything

53. Example

Encrypted disk + stolen encryption key:

confidentiality may still fail.

Security depends on:

• encryption;

• key protection;

• authentication;

• access control.

Part XXXVII — Data in Transit

54. Definition

Data in transit is information moving between systems or locations.

Examples:

• browser to web server;

• application to database;

• site-to-site communication.

Part XXXVIII — Transit Protection

55. Objectives

Protect:

• confidentiality;

• integrity;

• endpoint authenticity

as appropriate.

Part XXXIX — At Rest vs In Transit

56.

Part XL — Data Remanence

57. Remanence

Deleting a file may remove:

references to the data

without necessarily making the underlying content unrecoverable.

Part XLI — Ordinary Delete Is Not Sanitization

58. Critical Exam Principle

DELETE FILE

     ≠

SANITIZE MEDIA

Part XLII — Current Media Sanitization Standard

59. NIST SP 800-88 Rev. 2

The current NIST media-sanitization publication is SP 800-88 Rev. 2, finalized in September 2025 and replacing Rev. 1. It defines sanitization around rendering access to target data infeasible for an appropriate level of effort.

Part XLIII — Sanitization Methods

60. Current Methods

NIST SP 800-88 Rev. 2 retains three major sanitization methods:

Clear

Purge

Destroy.

Part XLIV — Clear

61. Clear

NIST describes Clear as applying logical techniques to user-addressable storage locations to protect against simple non-invasive recovery using the normal device interface.

62. Conceptual Use

MEDIA

   ↓

LOGICAL SANITIZATION

   ↓

MEDIA MAY REMAIN USABLE

Part XLV — Purge

63. Purge

NIST defines Purge as applying logical or physical techniques so recovery of target data becomes infeasible using state-of-the-art laboratory techniques.

Part XLVI — Destroy

64. Destroy

Destroy renders recovery infeasible and leaves the media unable to continue serving as data storage.

65. Basic Comparison

Always follow the organization's current approved sanitization standard and media-specific requirements.

Part XLVII — Cryptographic Erase

66. CE

NIST SP 800-88 Rev. 2 defines cryptographic erase as a Purge technique in which key sanitization is applied to the keys protecting encrypted target data, making recovery of the decrypted target data infeasible.

67. Concept

ENCRYPTED DATA

     │

     ▼

PROTECTED BY KEY

     │

     ▼

SANITIZE REQUIRED KEY

     │

     ▼

DECRYPTION INFEASIBLE

Part XLVIII — Cryptographic Erase Requirement

68. Important Limitation

Cryptographic erase relies on:

• proper encryption;

• correct key coverage;

• secure key sanitization.

If some target data was never properly encrypted:

destroying the encryption key does not sanitize that plaintext.

Part XLIX — Sanitization Program

69. Rev. 2 Focus

NIST's 2025 revision shifts emphasis toward establishing an organizational sanitization program and aligning decisions to the sensitivity of the information, rather than treating sanitization solely as a device-by-device technical procedure.

Part L — Sanitization Validation

70. Do Not Assume

A sanitization process should provide confidence that:

the intended sanitization outcome was achieved.

Rev. 2 places stronger emphasis on sanitization validation.

Part LI — Media Reuse

71. Reuse

Before media containing sensitive data is assigned to:

• a different user;

• different organization;

• different security context,

appropriate sanitization may be required.

Part LII — Disposal

72. Disposal

NIST distinguishes disposal as a release outcome after determining media does not contain sensitive data, either because it never did or because sanitization has removed the sensitive data.

Part LIII — Patch Management

73. Current CISSP Objective

Objective 7.8 requires candidates to:

implement and support patch and vulnerability management.

Part LIV — Patch Management Is Preventive Maintenance

74. NIST View

NIST SP 800-40 Rev. 4 frames enterprise patch management as preventive maintenance required to reduce compromises, breaches, outages, and other adverse events.

Part LV — Patch Lifecycle

75. NIST's Core Sequence

NIST describes enterprise patch management as:

IDENTIFY

   ↓

PRIORITIZE

   ↓

ACQUIRE

   ↓

INSTALL

   ↓

VERIFY

Part LVI — Patch

76. Patch Concept

A patch modifies software or firmware to correct issues such as:

• vulnerabilities;

• defects;

• operational problems.

Part LVII — Update

77. Update

An update may include:

• fixes;

• security improvements;

• functionality changes.

Terminology varies among vendors.

Part LVIII — Upgrade

78. Upgrade

An upgrade typically moves a product to a newer major version or release.

It may introduce substantial:

• functional;

• architectural;

• compatibility

changes.

Part LIX — Do Not Overfocus on Terminology

79. Exam Mindset

The important operational idea is:

Security-relevant software and firmware changes need risk-based management.

Part LX — Patch Identification

80. First Question

Are we affected?

Security teams need:

• asset inventory;

• software versions;

• vulnerability intelligence.

Part LXI — Asset Mapping

81.

NEW PATCH / VULNERABILITY

       │

       ▼

WHICH PRODUCTS?

       │

       ▼

WHICH ASSETS?

       │

       ▼

WHICH BUSINESS SERVICES?

Part LXII — Patch Prioritization

82. Not Every Patch Has Equal Urgency

Consider:

• vulnerability severity;

• known exploitation;

• exposure;

• asset criticality;

• compensating controls.

Lesson Twenty-Two covered this vulnerability-risk model in detail.

Part LXIII — Patch Risk vs Change Risk

83. Central Operations Problem

Patching creates two risks:

Risk of Not Patching

• exploitation;

• compromise.

Risk of Patching

• compatibility failure;

• service outage.

Part LXIV — Balance

84.

SECURITY RISK

OF DELAY

     ↕

OPERATIONAL RISK

OF CHANGE

The objective is not:

patch everything blindly.

It is:

reduce overall organizational risk.

Part LXV — Patch Acquisition

85. Trusted Source

Obtain security updates from:

• trusted;

• authenticated;

• authorized

sources.

Part LXVI — Supply-Chain Consideration

86. Why?

A malicious or modified update can become:

an enterprise-wide compromise mechanism.

Validate update provenance as appropriate.

Part LXVII — Patch Testing

87. Test Before Broad Deployment

Where operationally practical:

PATCH

   ↓

TEST ENVIRONMENT

   ↓

FUNCTIONAL TEST

   ↓

SECURITY TEST

   ↓

APPROVE

   ↓

PRODUCTION

Part LXVIII — Testing Goal

88. Verify

• application compatibility;

• system stability;

• required security correction.

Part LXIX — Test Environment Limitation

89. No Test Environment Is Perfect

Production may differ.

Therefore even tested patches require:

• monitoring;

• rollback planning.

Part LXX — Staged Deployment

90. Pilot

Deploy first to:

• test group;

• limited production population.

91. Benefit

Potential failures affect:

fewer systems initially.

Part LXXI — Phased Deployment

92.

TEST

  ↓

PILOT

  ↓

PHASE 1

  ↓

PHASE 2

  ↓

ENTERPRISE

Part LXXII — Maintenance Window

93. Maintenance Window

Scheduled period for controlled system maintenance.

Benefits:

• stakeholder awareness;

• reduced operational disruption;

• support availability.

Part LXXIII — Maintenance Window Is Not an Excuse

94. Active Exploitation

If a critical vulnerability is actively exploited, waiting weeks for a normal maintenance window may create unacceptable risk.

Part LXXIV — Emergency Patching

95. Emergency Process

CRITICAL THREAT

      ↓

RAPID RISK ASSESSMENT

      ↓

EXPEDITED TESTING

      ↓

EMERGENCY AUTHORIZATION

      ↓

DEPLOY

      ↓

MONITOR

      ↓

DOCUMENT / REVIEW

Part LXXV — Emergency Does Not Mean Uncontrolled

96. Critical Principle

Emergency patching may shorten normal procedures.

It should not eliminate:

• accountability;

• authorization;

• documentation;

• verification.

Part LXXVI — Rollback Plan

97. Before Deployment

Ask:

What happens if this patch breaks production?

98. Backout

Possible approaches:

• uninstall patch;

• restore snapshot;

• restore known configuration;

• fail over.

The correct mechanism depends on the system.

Part LXXVII — Rollback Risk

99. Security Caveat

Rolling back a security patch can:

restore the vulnerability.

Management must understand the tradeoff.

Part LXXVIII — Patch Verification

100. NIST Includes Verification

NIST's definition explicitly includes verifying patch installation.

101. Critical Exam Principle

PATCH DEPLOYED

     ≠

PATCH VERIFIED

Part LXXIX — Verification Methods

102. Examples

• version check;

• authenticated scan;

• vulnerability retest;

• configuration verification.

Part LXXX — Patch Failure

103. Failure Scenarios

• deployment failed;

• system never rebooted;

• package installed incorrectly;

• vulnerable component remains.

Part LXXXI — Patch Compliance

104. Measure Correctly

Do not only ask:

Did the patch tool send it?

Ask:

Are affected systems actually remediated?

Part LXXXII — Firmware

105. Patch Management Is Broader Than Operating Systems

Consider:

• routers;

• firewalls;

• storage devices;

• appliances;

• firmware;

• hypervisors.

Part LXXXIII — Third-Party Applications

106. Common Blind Spot

Organizations may patch:

Windows

while ignoring:

• browsers;

• PDF software;

• database software;

• management tools.

Part LXXXIV — End of Life

107. EOL

End of Life generally means a product or version has reached a defined lifecycle endpoint.

Exact vendor terminology varies.

Part LXXXV — End of Support

108. EOS

End of Support generally means the vendor no longer provides the expected support or security updates.

Part LXXXVI — Why EOS Is Security-Relevant

109. Unsupported Product

When a new vulnerability appears:

VULNERABILITY

     ↓

PATCH?

     ↓

NO VENDOR FIX

Risk can become increasingly difficult to manage.

Part LXXXVII — Unsupported Systems

110. Preferred Long-Term Solution

Normally:

upgrade, replace, migrate, or retire.

Part LXXXVIII — Compensating Controls

111. If Immediate Replacement Is Impossible

Possible risk-reducing measures include:

• segmentation;

• access restriction;

• application allowlisting;

• monitoring;

• isolation.

112. But Do Not Confuse Mitigation With Fix

The unsupported technology remains:

a lifecycle risk.

Part LXXXIX — Vulnerability Management Connection

113.

VULNERABILITY MANAGEMENT

"What needs fixing?"

       │

       ▼

PATCH MANAGEMENT

"How do we deploy corrective updates safely?"

Part XC — Change Management

114. Current CISSP Objective

Objective 7.9 requires candidates to understand and participate in:

change management processes.

Part XCI — Why Change Creates Risk

115. Changes Can Affect

• confidentiality;

• integrity;

• availability;

• compliance;

• interoperability.

Part XCII — Change Management Goal

116.

Ensure necessary changes occur in a controlled, understood, authorized, and recoverable manner.

Part XCIII — Configuration Management vs Change Management

117. Configuration Management

Answers:

What is the approved state?

118. Change Management

Answers:

How may the approved state be changed?

Part XCIV — Relationship

119.

BASELINE

   │

   ▼

CHANGE REQUEST

   │

   ▼

ANALYZE

   │

   ▼

AUTHORIZE

   │

   ▼

IMPLEMENT

   │

   ▼

VERIFY

   │

   ▼

NEW BASELINE

Part XCV — Change Request

120. Request

A change request should clearly describe:

• proposed modification;

• purpose;

• affected systems;

• requester.

Part XCVI — Business Justification

121. Why Change?

Valid reasons may include:

• security patch;

• new capability;

• vulnerability remediation;

• performance improvement;

• compliance requirement.

Part XCVII — Impact Analysis

122. Before Approval

Ask:

• Which systems depend on this?

• Could security weaken?

• Could availability fail?

• Could users be affected?

Part XCVIII — Security Impact

123. Example

Business requests:

Enable legacy protocol for compatibility.

Security asks:

What new exposure does this create?

Part XCIX — Dependency Analysis

124.

CHANGE DATABASE

      │

      ├── APP A

      ├── APP B

      └── REPORTING SERVICE

Changing one component may affect several business processes.

Part C — Change Authorization

125. Authorized Change

Appropriate authority should approve changes according to:

• risk;

• scope;

• impact;

• organizational policy.

Part CI — Separation of Duties

126. High-Risk Example

One administrator:

• requests change;

• approves change;

• implements change;

• validates own work.

This may create excessive concentration of control.

Part CII — Stronger Model

127.

REQUESTER

    ↓

REVIEW / APPROVAL

    ↓

IMPLEMENTER

    ↓

VALIDATION

Exact roles depend on organization size and risk.

Part CIII — Change Advisory Process

128. CAB Concept

Some organizations use a Change Advisory Board or similar process to evaluate changes.

The CISSP exam focuses more on:

controlled risk-based approval

than on memorizing a specific committee structure.

Part CIV — Standard Change

129. Common Operational Category

A standard change is commonly used for a well-understood, repeatable, preauthorized change.

Example:

Approved routine workstation update.

Terminology varies by organization.

Part CV — Normal Change

130. Normal Change

A normal change typically follows the organization's full review and authorization workflow.

Part CVI — Emergency Change

131. Emergency Change

Needed when delay could create unacceptable:

• security;

• safety;

• operational

risk.

Part CVII — Important Exam Rule

132.

Emergency ≠ Uncontrolled

An emergency process should still provide:

• authority;

• documentation;

• verification;

• post-change review.

Part CVIII — Testing the Change

133. Test

Where practical:

• functional test;

• security test;

• interoperability test.

Part CIX — Change Implementation Plan

134. Plan

Document:

• steps;

• responsible personnel;

• schedule;

• dependencies;

• communications.

Part CX — Backout Plan

135. Before Change

Define:

how to restore service if implementation fails.

136. Backout Trigger

Example:

CHANGE STARTS

      ↓

ERROR RATE > LIMIT?

   ┌──┴──┐

  NO    YES

  │      │

CONTINUE BACKOUT

Part CXI — Backups Before Change

137. Depending on System

Back up:

• configuration;

• data;

• system image

where necessary to support recovery.

Part CXII — Communication

138. Stakeholders

Some changes require notifying:

• operations;

• help desk;

• users;

• business owners;

• security.

Part CXIII — Scheduling

139. Consider

• business critical periods;

• staffing;

• dependencies;

• recovery time.

Part CXIV — Implementation

140. Follow Approved Plan

Avoid unnecessary deviations.

If conditions differ substantially:

stop and reassess when appropriate.

Part CXV — Post-Change Verification

141. Ask

• Does functionality work?

• Is security intact?

• Are logs generated?

• Are expected configurations present?

Part CXVI — Post-Implementation Review

142. PIR

After significant or failed changes, review:

• outcome;

• unexpected effects;

• lessons learned.

Part CXVII — Failed Change

143. Example

Patch deployment causes application outage.

Correct response:

DETECT FAILURE

      ↓

BACKOUT / RECOVER

      ↓

STABILIZE

      ↓

INVESTIGATE

      ↓

CORRECT PLAN

      ↓

RETEST

Part CXVIII — Update Documentation

144. Critical Step

If the configuration changes legitimately:

update the documentation and baseline.

Otherwise monitoring may incorrectly flag the new approved state as drift.

Part CXIX — New Baseline

145.

OLD APPROVED STATE

       ↓

AUTHORIZED CHANGE

       ↓

VERIFIED NEW STATE

       ↓

UPDATED BASELINE

Part CXX — Unauthorized Change Detection

146. Example

File-integrity monitoring reports:

production firewall policy changed at 02:00.

No change ticket exists.

This should trigger:

investigation.

Part CXXI — Unauthorized Does Not Automatically Mean Malicious

147. Possible Explanations

• emergency action;

• administrator error;

• attack.

Investigate.

Part CXXII — File Integrity Monitoring

148. FIM Concept

A file-integrity system can detect unexpected changes to:

• critical files;

• configurations;

• system components.

Part CXXIII — Drift + Logging

149. Better Context

CONFIGURATION DIFFERENCE

       +

CHANGE RECORD

       +

ADMIN LOGS

       =

AUTHORIZED OR SUSPICIOUS?

Part CXXIV — Configuration and Change Evidence

150. Useful Records

• request;

• approval;

• test results;

• implementation logs;

• post-change validation.

Part CXXV — Change Metrics

151. Examples

• percentage successful changes;

• emergency-change rate;

• rollback rate;

• unauthorized-change count.

Part CXXVI — High Emergency-Change Rate

152. Interpretation

A large number of emergency changes may indicate:

• poor planning;

• unstable systems;

• immature patch processes.

But analyze context before concluding.

Part CXXVII — Change Failure Rate

153.

FAILED CHANGES

────────────── × 100

TOTAL CHANGES

Can provide useful operational information.

Part CXXVIII — Configuration Compliance

154. Metric

SYSTEMS MATCHING BASELINE

──────────────────────── × 100

SYSTEMS IN SCOPE

Part CXXIX — The Security Operations Triangle

155.

       SECURITY

         /\

        /  \

       /    \

CHANGE ---- AVAILABILITY

Strong operations balances:

• protection;

• required change;

• business continuity.

Part CXXX — Patching Without Change Management

156. Risk

Installing an untested patch directly in production could:

• fix a vulnerability;

• create an outage.

Part CXXXI — Change Management Without Patching

157. Opposite Risk

An organization can make change control so bureaucratic that:

critical patches take months.

Process itself can then increase security risk.

Part CXXXII — Balanced Governance

158.

Controls should reduce risk, not simply produce paperwork.

Part CXXXIII — Emergency Vulnerability Scenario

159.

Critical Internet-facing product.

Active exploitation.

Vendor patch available.

Correct sequence:

ASSESS

  ↓

TEST AS PRACTICAL

  ↓

EMERGENCY AUTHORIZATION

  ↓

DEPLOY

  ↓

VERIFY

  ↓

MONITOR

  ↓

DOCUMENT

Part CXXXIV — Legacy System Scenario

160.

Legacy application cannot support current operating system.

Options should consider:

• business dependency;

• segmentation;

• restricted access;

• monitoring;

• migration plan.

Part CXXXV — Cloud Configuration Management

161. Cloud Resources Also Drift

Examples:

• public storage;

• excessive security-group access;

• altered IAM policies.

Part CXXXVI — Cloud Automation

162.

APPROVED CLOUD TEMPLATE

        ↓

VERSION CONTROL

        ↓

AUTOMATED DEPLOYMENT

        ↓

CONTINUOUS POLICY CHECK

Part CXXXVII — Ephemeral Infrastructure

163. Modern Benefit

Instead of manually repairing a badly configured workload:

replace it with a newly deployed approved image.

This can reduce configuration drift when implemented correctly.

Part CXXXVIII — But Template Security Is Critical

164.

Immutable deployment built from:

vulnerable template

is still:

vulnerable.

Part CXXXIX — Containers

165. Container Operations

Consider:

• approved base images;

• vulnerability status;

• runtime permissions;

• version control.

Part CXL — Network Device Configuration

166. Backup Network Configurations

Routers and firewalls require:

• approved configuration;

• controlled changes;

• recovery copies.

Part CXLI — Firewall Rule Changes

167. Example

Request:

Allow any source to database port temporarily.

Security should examine:

• business need;

• scope;

• duration;

• alternatives.

Part CXLII — Temporary Change

168. Expiration

Temporary firewall change should not become:

permanent by accident.

Use:

• defined expiration;

• review;

• automatic removal where practical.

Part CXLIII — Certificates and Configurations

169. Operational Configuration Includes

• certificates;

• trusted roots;

• TLS settings;

• key locations.

Poor change control can break:

• security;

• availability.

Part CXLIV — Backup Configuration Protection

170. Configuration Backups Can Be Sensitive

They may contain:

• addresses;

• usernames;

• secrets;

• architecture details.

Protect them accordingly.

Part CXLV — Media and Cloud

171. Logical Media

Modern environments complicate traditional media management because storage may be:

• virtualized;

• cloud-hosted;

• provider-managed.

NIST's 2025 sanitization revision explicitly expanded attention to modern sanitization programs and logical/cloud-oriented storage considerations.

Part CXLVI — Cloud Disposal

172. Important Question

When a cloud resource is deleted:

what happens to the underlying data?

Security requirements should account for:

• provider controls;

• contracts;

• encryption;

• key management.

Part CXLVII — Encryption as Lifecycle Control

173. Encryption Can Support Resource Protection

But encryption does not eliminate the need for:

• access control;

• sanitization planning;

• key lifecycle management.

Part CXLVIII — Destroy the Key?

174. Important Qualification

Cryptographic erase can be powerful when its prerequisites are satisfied, but it is not equivalent to casually deleting:

any arbitrary key.

NIST treats CE as a defined purge sanitization technique dependent on the keys protecting encrypted target data.

Part CXLIX — Patch vs Compensating Control

175. Preferred Question

Can the vulnerability be remediated?

If not immediately:

Can exposure be materially reduced until permanent correction?

Part CL — Compensating Control Expiration

176. Do Not Forget

A temporary mitigation should remain linked to:

• the open vulnerability;

• migration/patch plan;

• review date.

Part CLI — Root Cause

177. Repeated Configuration Failures

If 300 systems repeatedly violate the baseline:

fix the provisioning or automation process.

Part CLII — Root Cause and Change

178.

BAD TEMPLATE

    ↓

MANY SYSTEMS

    ↓

MANY FINDINGS



BETTER:

FIX TEMPLATE

    ↓

REDEPLOY / REMEDIATE

Part CLIII — SierraTec Secure BASELINE Model

179. BASELINE

Use BASELINE for configuration-management questions.

B — Build the Approved State

Define the secure configuration.

A — Assign Ownership

Know who owns each configuration item.

S — Secure the Minimum Functionality

Remove unnecessary services and settings.

E — Establish Controlled Provisioning

Deploy from trusted templates.

L — Log and Monitor Changes

Detect drift and unauthorized modification.

I — Inspect Against Baseline

Continuously compare intended and actual state.

N — Normalize Authorized Changes

Update documentation after approved modifications.

E — Eliminate Drift

Remediate unauthorized or obsolete configuration.

Part CLIV — BASELINE Diagram

180.

B

BUILD APPROVED STATE

       │

       ▼

A

ASSIGN OWNERSHIP

       │

       ▼

S

SECURE MINIMUM

       │

       ▼

E

ESTABLISH PROVISIONING

       │

       ▼

L

LOG CHANGES

       │

       ▼

I

INSPECT STATE

       │

       ▼

N

NORMALIZE APPROVED CHANGE

       │

       ▼

E

ELIMINATE DRIFT

Part CLV — SierraTec Secure PATCH Model

181. PATCH

Use PATCH for patch questions.

P — Pinpoint Affected Assets

Determine exposure.

A — Assess Risk and Priority

Consider severity, exploitation, and business impact.

T — Test and Prepare

Validate compatibility and rollback.

C — Change Through Controlled Deployment

Use authorized deployment processes.

H — Hunt for Verification

Confirm the vulnerability is actually removed.

Part CLVI — PATCH Diagram

182.

P

PINPOINT

   │

   ▼

A

ASSESS

   │

   ▼

T

TEST

   │

   ▼

C

CONTROLLED CHANGE

   │

   ▼

H

HUNT / VERIFY

Part CLVII — SierraTec Secure CHANGE Model

183. CHANGE

Use CHANGE when evaluating operational change questions.

C — Clarify the Need

Why is the change required?

H — Highlight Impact

What systems, risks, and dependencies are affected?

A — Authorize Appropriately

Obtain approval proportional to risk.

N — Navigate Implementation

Follow the tested plan.

G — Go Back if Necessary

Maintain rollback/recovery capability.

E — Examine and Establish New State

Validate results and update the baseline.

Part CLVIII — CHANGE Diagram

184.

C

CLARIFY NEED

     │

     ▼

H

HIGHLIGHT IMPACT

     │

     ▼

A

AUTHORIZE

     │

     ▼

N

NAVIGATE IMPLEMENTATION

     │

     ▼

G

GO BACK IF NEEDED

     │

     ▼

E

EXAMINE / ESTABLISH

Part CLIX — Worked Scenario 1: Baseline

185.

An administrator wants to know the formally approved configuration for a production server.

Which artifact is MOST relevant?

A. Configuration baseline
B. Threat feed
C. Chain of custody
D. RPO

Correct Answer

A

Rationale

The baseline defines the approved configuration state against which actual configuration can be compared.

Part CLX — Scenario 2: Drift

186.

A security scan discovers that remote administration was enabled months ago for troubleshooting and never disabled.

What problem is MOST evident?

A. Configuration drift
B. Data remanence
C. Business continuity
D. Federation failure

Correct Answer

A

Part CLXI — Scenario 3: Automation

187.

An automated deployment system pushes an insecure firewall rule to 4,000 servers.

What lesson is MOST important?

A. Automation increases both consistency and the potential scale of configuration errors.

B. Automation eliminates configuration risk.

C. Manual processes are always more secure.

D. Firewalls need no baselines.

Correct Answer

A

Part CLXII — Scenario 4: Gold Image

188.

Every new server has the same outdated vulnerable service because it exists in the corporate gold image.

What is the BEST long-term action?

A. Correct the approved image/template and remediate affected systems.

B. Fix each system manually forever.

C. Stop scanning new servers.

D. Accept the service permanently.

Correct Answer

A

Part CLXIII — Scenario 5: Media

189.

A USB drive containing confidential business information must be assigned to a different organizational security context.

What should occur FIRST?

A. Determine and apply the approved media-sanitization requirement.

B. Rename the files.

C. Delete the folder only.

D. Change the USB label.

Correct Answer

A

Part CLXIV — Scenario 6: Delete vs Sanitize

190.

An administrator deletes files from an SSD and empties the recycle bin before selling the device.

What is the PRIMARY concern?

A. Ordinary deletion may not satisfy sanitization requirements.

B. The device can no longer store data.

C. Deletion automatically equals Purge.

D. The drive is cryptographically erased.

Correct Answer

A

Part CLXV — Scenario 7: Clear

191.

Which sanitization method primarily uses logical techniques against simple, non-invasive recovery through the ordinary device interface?

A. Clear
B. Destroy
C. Physical security inspection
D. Classification

Correct Answer

A

NIST SP 800-88 Rev. 2 defines Clear in this manner.

Part CLXVI — Scenario 8: Purge

192.

Which NIST media-sanitization method seeks to make target-data recovery infeasible using state-of-the-art laboratory techniques while potentially preserving media usability?

A. Purge
B. Ordinary delete
C. Rename
D. Archive

Correct Answer

A

Part CLXVII — Scenario 9: Destroy

193.

Sensitive media is damaged and cannot be reliably sanitized for reuse. Policy requires the strongest approved disposition and the media need not be reused.

Which general method BEST fits?

A. Destroy
B. Rename
C. Compress
D. Reformat only

Correct Answer

A

Part CLXVIII — Scenario 10: Cryptographic Erase

194.

A storage platform securely encrypts all target data with controlled keys, and the approved sanitization process securely sanitizes the necessary confidentiality-protecting keys.

Which technique may be appropriate?

A. Cryptographic erase
B. Plain file deletion
C. Access logging
D. RAID rebuilding

Correct Answer

A

Part CLXIX — Scenario 11: Patch Priority

195.

A high-severity vulnerability is actively exploited on an Internet-facing authentication server.

What should happen?

A. Expedite risk-based patching or mitigation through the approved emergency process.

B. Wait automatically for the next quarterly maintenance cycle.

C. Ignore it if antivirus is installed.

D. Remove it from vulnerability reports.

Correct Answer

A

Part CLXX — Scenario 12: Patch Testing

196.

A vendor releases a security patch for a mission-critical system. The patch has not been tested with the organization's critical application.

What should normally occur?

A. Test compatibility as practical while balancing the risk of delaying remediation.

B. Never patch.

C. Deploy blindly regardless of operational risk.

D. Permanently accept the vulnerability.

Correct Answer

A

Part CLXXI — Scenario 13: Verification

197.

The patch-management server reports a successful deployment, but a vulnerability scanner still detects the weakness.

What should security conclude?

A. Remediation has not yet been demonstrated and requires investigation.

B. The finding should automatically close.

C. Patch server status overrides all validation.

D. Vulnerability scanning should stop.

Correct Answer

A

Part CLXXII — Scenario 14: End of Support

198.

A critical application requires an operating system for which the vendor no longer provides security fixes.

What is the BEST long-term security strategy?

A. Plan migration/replacement while applying appropriate interim compensating controls.

B. Keep it permanently because it still boots.

C. Disable all monitoring.

D. Remove it from inventory.

Correct Answer

A

Part CLXXIII — Scenario 15: Change Approval

199.

A database administrator wants to modify a production security configuration without an approved change because the change “looks harmless.”

What is the BEST action?

A. Follow the appropriate change-management authorization process.

B. Implement first and document only if something breaks.

C. Bypass testing.

D. Disable logging.

Correct Answer

A

Part CLXXIV — Scenario 16: Emergency Change

200.

A critical security vulnerability requires immediate firewall changes during an active attack.

Which approach is BEST?

A. Use the approved emergency-change process, document the change, and review it afterward.

B. Make undocumented changes with no accountability.

C. Wait indefinitely for the routine monthly meeting.

D. Disable the firewall.

Correct Answer

A

Part CLXXV — Scenario 17: Rollback

201.

A production patch causes severe application failure.

What should the team use if appropriate and preplanned?

A. Backout/rollback procedure.

B. Ignore the outage.

C. Delete the change ticket.

D. Remove all backups.

Correct Answer

A

Part CLXXVI — Scenario 18: Baseline Update

202.

An authorized security configuration change is successfully implemented and validated.

What should happen NEXT?

A. Update relevant documentation/baseline to reflect the new approved state.

B. Continue treating the new configuration as unauthorized drift.

C. Delete the change evidence.

D. Remove monitoring.

Correct Answer

A

Part CLXXVII — Scenario 19: Separation of Duties

203.

One administrator can request, approve, implement, and independently certify all high-risk changes.

What is the PRIMARY concern?

A. Insufficient separation of duties.

B. Too much patch testing.

C. Media sanitization.

D. Encryption overhead.

Correct Answer

A

Part CLXXVIII — Scenario 20: Temporary Rule

204.

A firewall exception was approved for a two-day vendor maintenance period but remains active six months later.

What failed?

A. Temporary-change lifecycle control and review.

B. Cryptographic erase.

C. Incident forensics.

D. Data classification.

Correct Answer

A

Part CLXXIX — Common CISSP Exam Traps

205. Trap — Baseline Means Factory Default

No.

A baseline represents:

the organization's formally approved configuration state.

206. Trap — Benchmark and Baseline Are Identical

Not necessarily.

Benchmark:

reference recommendation.

Baseline:

approved organizational state.

207. Trap — Configuration Management Is Only Inventory

No.

Inventory is one part.

Configuration management also includes:

• baselines;

• change control;

• monitoring.

208. Trap — Automation Eliminates Configuration Error

No.

Automation can scale errors dramatically.

209. Trap — Configuration Drift Is Always an Attack

No.

It can be:

• authorized but undocumented;

• accidental;

• malicious.

Investigate.

210. Trap — Deleting a File Sanitizes the Media

No.

Deletion and sanitization are different.

211. Trap — Formatting Always Sanitizes

Not automatically.

Use the approved sanitization method appropriate to:

• media;

• information sensitivity;

• organizational requirements.

212. Trap — NIST SP 800-88 Rev. 1 Is Still the Current Publication

No.

Rev. 2 became final in September 2025 and superseded Rev. 1.

213. Trap — Clear, Purge, and Destroy Are Interchangeable

No.

They provide different sanitization outcomes.

214. Trap — Destroy Preserves Media for Reuse

No.

NIST defines Destroy so the media can no longer be used to store data.

215. Trap — Cryptographic Erase Works Even If Target Data Was Never Encrypted

No.

CE depends on the applicable target data being protected by the keys being sanitized.

216. Trap — Encryption Eliminates Need for Media Management

No.

Encrypted media still requires:

• inventory;

• key management;

• disposition controls.

217. Trap — Highest Severity Patch Always Goes First

Not automatically.

Prioritize according to:

• exploit activity;

• exposure;

• asset criticality;

• operational impact.

218. Trap — Every Patch Should Be Installed Immediately Without Testing

No.

Testing reduces availability and compatibility risk where circumstances allow.

219. Trap — Testing Means Delaying Critical Security Fixes Indefinitely

No.

Active exploitation may require expedited procedures.

220. Trap — Patch Tool Reports Success, Therefore Vulnerability Is Gone

No.

Verify.

NIST's patch-management model explicitly includes verification.

221. Trap — Unsupported System Is Safe If No Current Finding Exists

No.

Lack of vendor security updates creates future lifecycle risk.

222. Trap — Compensating Control Permanently Fixes an Unsupported Product

No.

It reduces risk.

It does not restore vendor support.

223. Trap — Emergency Change Means Skip Documentation

No.

Use expedited governance, then perform appropriate post-change review.

224. Trap — Change Management Exists to Stop Change

No.

Its purpose is:

enable necessary change safely.

225. Trap — CAB Must Approve Every Change Everywhere

Not necessarily.

Organizations implement change authorization differently.

The CISSP principle is:

appropriate review and authority proportional to risk.

226. Trap — Rollback Is Always Safe

No.

Rollback may:

• reintroduce vulnerabilities;

• lose data;

• create incompatibility.

It must be planned and evaluated.

227. Trap — Approved Change Does Not Need Baseline Update

Incorrect.

The approved state should reflect legitimate operational reality.

Part CLXXX — Knowledge Check

228. Question 1

What is the main purpose of a configuration baseline?

A. Define the approved system state.
B. Identify attackers.
C. Encrypt backups.
D. Perform incident response.

Correct Answer

A

229. Question 2

What is configuration drift?

A. Deviation from the approved configuration over time.
B. Loss of encryption keys.
C. Data classification.
D. Network latency.

Correct Answer

A

230. Question 3

Which CISSP Domain 7 objective explicitly lists provisioning, baselining, and automation?

A. 7.3 Configuration Management
B. 7.12 DR testing
C. 7.15 Personnel safety
D. 7.1 Investigations

Correct Answer

A

231. Question 4

What is the biggest security benefit of a secure gold image?

A. Consistent standardized provisioning.
B. Elimination of patching.
C. Elimination of monitoring.
D. Unlimited administrative access.

Correct Answer

A

232. Question 5

What is the risk of an insecure gold image?

A. The weakness can propagate to every deployed system.
B. It affects only one system.
C. Automation corrects it automatically.
D. It cannot contain software vulnerabilities.

Correct Answer

A

233. Question 6

Which is an example of data at rest?

A. Database stored on disk.
B. TLS network session.
C. Voice call in transit.
D. Packet crossing a router.

Correct Answer

A

234. Question 7

Which is an example of data in transit?

A. Application data moving over a network.
B. Archived disk backup.
C. SSD in a safe.
D. Offline USB device.

Correct Answer

A

235. Question 8

Which current NIST publication governs media sanitization guidance?

A. SP 800-88 Rev. 2
B. SP 800-88 Rev. 1
C. RFC 4120
D. SP 800-61 Rev. 2

Correct Answer

A

236. Question 9

Which sanitization method is intended to protect against simple non-invasive recovery using normal device interfaces?

A. Clear
B. Destroy
C. Classification
D. Backup

Correct Answer

A

237. Question 10

Which sanitization method seeks to make recovery infeasible using state-of-the-art laboratory techniques?

A. Purge
B. Ordinary delete
C. Rename
D. Compress

Correct Answer

A

238. Question 11

Which sanitization method renders media unusable for future data storage?

A. Destroy
B. Clear
C. File deletion
D. Encryption only

Correct Answer

A

239. Question 12

What is cryptographic erase?

A. A Purge technique involving sanitization of confidentiality-protecting keys for encrypted target data.
B. Deleting a filename.
C. Formatting a document.
D. Encrypting a network session.

Correct Answer

A

240. Question 13

Which publication currently provides NIST enterprise patch-management planning guidance?

A. SP 800-40 Rev. 4
B. SP 800-40 Rev. 3
C. SP 800-86
D. SP 800-92

Correct Answer

A

241. Question 14

Which step is part of NIST's enterprise patch-management definition?

A. Verify installation.
B. Ignore operational compatibility.
C. Disable change control.
D. Permanently accept every vulnerability.

Correct Answer

A

242. Question 15

What is a primary reason to test patches?

A. Identify compatibility or stability problems before wider deployment.
B. Guarantee no future vulnerabilities.
C. Avoid all documentation.
D. Replace backups.

Correct Answer

A

243. Question 16

What is the BEST response to an actively exploited vulnerability when normal patch scheduling creates unacceptable delay?

A. Use an approved expedited/emergency patch process.
B. Ignore it.
C. Wait automatically.
D. Delete the vulnerability record.

Correct Answer

A

244. Question 17

What should occur after patch installation?

A. Verify remediation.
B. Assume success.
C. Stop vulnerability management.
D. Remove the asset inventory.

Correct Answer

A

245. Question 18

What is the main purpose of change management?

A. Enable necessary changes in a controlled manner.
B. Prevent all changes.
C. Eliminate security testing.
D. Replace configuration management.

Correct Answer

A

246. Question 19

What should a change-impact assessment identify?

A. Systems, risks, dependencies, and likely consequences.
B. Only the requester's name.
C. Only patch severity.
D. Password length.

Correct Answer

A

247. Question 20

What should happen after a successful authorized change?

A. Validate the outcome and update relevant configuration documentation/baselines.
B. Delete evidence.
C. Remove monitoring.
D. Treat the approved configuration as drift.

Correct Answer

A

Part CLXXXI — Original CISSP-Style Practice Questions

248. Practice Question 1

An enterprise wants to know whether production systems continue to match their approved hardening standards.

Which control is MOST directly useful?

A. Automated comparison against approved configuration baselines.
B. Annual user-awareness training.
C. Data classification alone.
D. Business continuity planning.

Correct Answer

A

249. Practice Question 2

An administrator temporarily enables an insecure service during troubleshooting but forgets to disable it.

Which operational process should MOST directly detect the condition?

A. Configuration monitoring/drift detection.
B. Media destruction.
C. Disaster recovery.
D. Personnel screening.

Correct Answer

A

250. Practice Question 3

An organization uses Infrastructure as Code but allows engineers to modify production infrastructure manually without updating the source configuration.

What is the GREATEST concern?

A. Actual infrastructure can drift from the approved managed configuration.
B. IaC automatically prevents every manual change.
C. Version control becomes unnecessary.
D. Patching is no longer required.

Correct Answer

A

251. Practice Question 4

A storage device contains sensitive data and is being transferred to a party with no authorization for that data.

What should drive the sanitization decision?

A. Information sensitivity, media characteristics, and approved sanitization requirements.
B. File names alone.
C. Device age alone.
D. Whether the drive appears empty.

Correct Answer

A

252. Practice Question 5

A security engineer proposes using cryptographic erase on storage whose sensitive data was only partially encrypted.

What is the PRIMARY concern?

A. Sanitizing encryption keys may not render unencrypted target data inaccessible.
B. Cryptographic erase destroys every storage device.
C. CE is not a sanitization technique.
D. Encryption keys do not affect data confidentiality.

Correct Answer

A

253. Practice Question 6

A patch has a high severity rating but applies only to an isolated laboratory system. Another patch addresses an actively exploited flaw on the organization's public VPN gateway.

Which should management prioritize?

A. The VPN gateway may deserve higher priority based on exposure and active exploitation.
B. Always patch strictly according to numerical severity.
C. The lab system must always come first.
D. Both should be ignored until annual maintenance.

Correct Answer

A

254. Practice Question 7

An emergency security update is deployed successfully to production.

What should occur after the immediate threat is addressed?

A. Verify the result, complete required documentation, and conduct appropriate post-change review.
B. Delete all records because the change was an emergency.
C. Never document emergency changes.
D. Disable vulnerability scanning.

Correct Answer

A

255. Practice Question 8

A patch fixes a remote-code-execution vulnerability but causes a critical business application to fail.

What should the security manager consider?

A. Use the approved recovery/backout process while rapidly reassessing exposure and alternative mitigations.
B. Leave the business application failed indefinitely.
C. Ignore the security risk.
D. Disable all change management.

Correct Answer

A

256. Practice Question 9

A network device has reached End of Support and the vendor will issue no further security fixes.

What is the BEST long-term approach?

A. Replace or migrate the unsupported technology while using appropriate interim risk controls.
B. Ignore the lifecycle status.
C. Permanently remove it from vulnerability management.
D. Assume it has no vulnerabilities because support ended.

Correct Answer

A

257. Practice Question 10

An engineer discovers a critical configuration problem and changes production immediately without following the normal process. The action successfully prevents compromise.

What should occur NEXT?

A. Document and review the emergency change under the authorized exception/emergency process.
B. Hide the change because it worked.
C. Delete logs.
D. Treat documentation as unnecessary.

Correct Answer

A

258. Practice Question 11

A change request includes implementation steps but no rollback procedure.

What is the PRIMARY concern?

A. Recovery may be difficult if the change fails.
B. Change management never requires recovery planning.
C. Every change always succeeds.
D. Rollback is only relevant to investigations.

Correct Answer

A

259. Practice Question 12

A firewall rule was approved for 30 days but has remained active for one year.

Which improvement BEST addresses the root problem?

A. Implement expiration/review controls for temporary changes.
B. Stop documenting firewall rules.
C. Permanently approve all temporary rules.
D. Disable configuration monitoring.

Correct Answer

A

260. Practice Question 13

A patch-management tool reports 99% success, but vulnerability scanning shows 15% of systems still exposed.

Which measure should management trust for security assurance?

A. Validate the discrepancy and focus on actual remediation evidence rather than deployment status alone.
B. Always trust the patch console.
C. Always trust only one tool.
D. Close all findings automatically.

Correct Answer

A

261. Practice Question 14

A cloud-development team deploys storage resources using a version-controlled secure template but later manually changes one bucket to public access.

What is the MOST important control gap?

A. Configuration drift/change monitoring.
B. Encryption at rest automatically failed.
C. Media destruction.
D. Disaster recovery planning.

Correct Answer

A

262. Practice Question 15

A security benchmark recommends disabling a service, but the business application legitimately requires it.

What should the organization do?

A. Evaluate the risk, document the justified organizational baseline, and apply appropriate protections.
B. Blindly follow the benchmark regardless of business requirements.
C. Ignore all benchmarks.
D. Remove change management.

Correct Answer

A

Part CLXXXII — Configuration Management Memory Table

Part CLXXXIII — Media Protection Memory Table

Part CLXXXIV — Sanitization Memory Table

The current NIST source for these methods is SP 800-88 Rev. 2.

Part CLXXXV — Patch Memory Table

NIST SP 800-40 Rev. 4 formally includes identification, prioritization, acquisition, installation, and verification in enterprise patch management.

Part CLXXXVI — Change Memory Table

Part CLXXXVII — Key Terms

Configuration Management

Discipline for establishing, controlling, documenting, and monitoring system configurations.

Security-Focused Configuration Management

Integration of information-security requirements into configuration management.

Configuration Item

Component placed under configuration control.

Configuration Baseline

Formally reviewed and approved configuration state used as a reference for future changes.

Benchmark

Reference configuration or security recommendation used to evaluate system settings.

Provisioning

Preparing and configuring a resource for use.

Hardening

Reducing unnecessary system functionality and attack surface.

Gold Image

Approved standardized image used for system deployment.

Configuration Drift

Deviation of operational configuration from the approved state.

Infrastructure as Code

Management of infrastructure through machine-readable, versionable definitions.

CMDB

Repository describing managed configuration items and relationships.

Resource Protection

Controls used to protect organizational information and resources during storage, use, transport, and disposition.

Data at Rest

Stored information.

Data in Transit

Information moving across communication channels.

Data Remanence

Residual data remaining after ordinary deletion or removal operations.

Media Sanitization

Actions intended to render target data recovery infeasible at the required level.

Clear

Logical sanitization protecting against simple non-invasive recovery techniques.

Purge

Sanitization intended to make target-data recovery infeasible using state-of-the-art laboratory techniques.

Destroy

Sanitization that makes target-data recovery infeasible and renders the media unusable for future storage.

Cryptographic Erase

Purge technique using sanitization of confidentiality-protecting cryptographic keys associated with encrypted target data.

Patch Management

Process for identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades.

Emergency Patch

Security update deployed using an expedited risk-controlled process because delay presents unacceptable exposure.

End of Life

Vendor-defined lifecycle stage at which a product/version reaches an end point.

End of Support

Point after which normal vendor support or security updates are no longer provided.

Change Management

Process for assessing, authorizing, implementing, documenting, and validating changes.

Change Request

Formal request describing a proposed modification.

Standard Change

Common operational term for a low-risk, repeatable, preauthorized change.

Normal Change

Common operational term for a change that follows ordinary review and approval.

Emergency Change

Change requiring expedited handling because normal delay creates unacceptable risk.

Backout Plan

Documented method for reversing or recovering from a failed change.

Post-Implementation Review

Evaluation performed after a change to confirm outcome and capture lessons.

CISSP Exam Focus

When you see a configuration-management question, think:

WHAT IS THE APPROVED STATE?

       ↓

WHO OWNS IT?

       ↓

IS THE ACTUAL STATE DIFFERENT?

       ↓

WAS THE DIFFERENCE AUTHORIZED?

       ↓

SHOULD BASELINE BE UPDATED

OR DRIFT REMEDIATED?

When you see a media-protection question:

WHAT DATA?

     ↓

HOW SENSITIVE?

     ↓

WHAT MEDIA?

     ↓

HOW IS IT USED / TRANSPORTED?

     ↓

WILL MEDIA BE REUSED OR RELEASED?

     ↓

WHAT SANITIZATION IS REQUIRED?

When you see a patch question:

ARE WE AFFECTED?

     ↓

HOW URGENT?

     ↓

CAN WE TEST?

     ↓

HOW DO WE DEPLOY SAFELY?

     ↓

WHAT IF IT FAILS?

     ↓

DID IT ACTUALLY FIX THE RISK?

When you see a change-management question:

WHY CHANGE?

     ↓

WHAT IS THE IMPACT?

     ↓

WHO AUTHORIZES?

     ↓

WAS IT TESTED?

     ↓

CAN WE RECOVER?

     ↓

DID IT WORK?

     ↓

IS THE NEW STATE DOCUMENTED?

Remember:

• Current CISSP Objective 7.3 explicitly identifies provisioning, baselining, and automation under Configuration Management.

• Current Objective 7.5 includes media management, media protection, data at rest, and data in transit.

• Current Objective 7.8 covers patch and vulnerability management.

• Current Objective 7.9 covers participation in change-management processes.

• A baseline is the approved state.

• A benchmark is generally a reference used to help build/evaluate that state.

• Configuration management is much broader than asset inventory.

• Secure provisioning prevents vulnerable default systems from entering production.

• Gold images improve consistency but can multiply errors if compromised or obsolete.

• Automation scales both good configuration and bad configuration.

• Drift should be detected and investigated.

• Authorized changes should result in updated baselines.

• Resource protection includes both stored and transmitted information.

• Ordinary deletion does not equal sanitization.

• NIST SP 800-88 Rev. 2 is the current final media-sanitization publication as of August 2026.

• Clear, Purge, and Destroy remain the primary NIST sanitization methods.

• Destroy means the media cannot subsequently be used for data storage.

• Cryptographic erase is a Purge technique and depends on proper encryption/key coverage.

• Sanitization decisions depend on information sensitivity and organizational requirements.

• NIST SP 800-40 Rev. 4 remains the final enterprise patch-management planning guidance and frames patching as preventive maintenance.

• Patch management includes verification—not only deployment.

• A successfully transmitted patch is not proof of remediation.

• Patching balances exploitation risk against operational/change risk.

• Active exploitation may justify expedited patching.

• Emergency processes should be controlled rather than abandoned.

• Unsupported products are lifecycle risks.

• Compensating controls reduce risk but do not make unsupported technology supported.

• Change management exists to enable safe change, not prevent all change.

• High-risk changes should include impact assessment, approval, testing, implementation planning, verification, and rollback.

• Separation of duties can reduce unauthorized or self-approved changes.

• Temporary changes need expiration and review.

• Configuration monitoring should distinguish approved change from unauthorized drift.

• Recovery planning should exist before risky production changes.

• After successful authorized change, update documentation and the approved baseline.

Lesson Summary

Lesson Twenty-Five connected four major security-operations disciplines:

CONFIGURATION MANAGEMENT

         │

         ▼

RESOURCE PROTECTION

         │

         ▼

PATCH MANAGEMENT

         │

         ▼

CHANGE MANAGEMENT

The configuration-management lifecycle is:

DEFINE SECURE STATE

       ↓

PROVISION

       ↓

MONITOR

       ↓

DETECT DRIFT

       ↓

CONTROL CHANGE

       ↓

VERIFY

       ↓

UPDATE BASELINE

NIST SP 800-128 emphasizes managing and monitoring system configurations to support security while maintaining business functionality.

You learned that a baseline is:

the formally approved state from which future configuration changes are controlled.

You then studied information and media protection:

CREATE

  ↓

STORE

  ↓

USE

  ↓

TRANSPORT

  ↓

REUSE

  ↓

SANITIZE

  ↓

DISPOSE

The current NIST media-sanitization guidance is SP 800-88 Rev. 2, finalized in September 2025.

Its core sanitization methods remain:

CLEAR

  ↓

PURGE

  ↓

DESTROY

with cryptographic erase defined as an applicable Purge technique based on sanitizing confidentiality-protecting keys for encrypted target data.

You then studied patch management:

IDENTIFY

  ↓

PRIORITIZE

  ↓

ACQUIRE

  ↓

TEST

  ↓

DEPLOY

  ↓

VERIFY

NIST SP 800-40 Rev. 4 emphasizes that enterprise patch management is preventive maintenance and includes verification after installation.

Finally, you studied change management:

REQUEST

   ↓

ANALYZE

   ↓

AUTHORIZE

   ↓

TEST

   ↓

IMPLEMENT

   ↓

VERIFY

   ↓

DOCUMENT

   ↓

NEW BASELINE

The three SierraTec Secure models for this lesson are:

BASELINE

Build → Assign → Secure → Establish → Log → Inspect → Normalize → Eliminate

PATCH

Pinpoint → Assess → Test → Controlled Change → Hunt/Verify

CHANGE

Clarify → Highlight → Authorize → Navigate → Go Back → Examine

The central Lesson Twenty-Five principle is:

Secure operations require a known and approved state. Organizations must provision systems from trusted configurations, protect information throughout its media lifecycle, patch security weaknesses according to risk, control operational changes, preserve recovery options, detect configuration drift, and verify that every approved change produces the intended secure result.

Exam Readiness Check

Before moving to Lesson Twenty-Six, make sure you can explain without reviewing:

• What configuration management is.

• What security-focused configuration management means.

• What a configuration item is.

• Asset inventory versus configuration inventory.

• What a baseline configuration is.

• Baseline versus benchmark.

• Why vendor defaults are not automatically secure baselines.

• What secure provisioning means.

• What a gold image is.

• Why a gold image can multiply vulnerabilities.

• What hardening means.

• What least functionality means.

• What configuration drift means.

• How drift can occur.

• How configuration monitoring detects drift.

• Why drift does not automatically mean malicious change.

• How automation helps configuration management.

• Why automation can scale errors.

• What Infrastructure as Code means.

• Why version control helps configuration security.

• What rollback means.

• What a CMDB represents conceptually.

• Why dependency mapping matters.

• What resource protection means.

• What media management means.

• Why removable media creates risk.

• Why media needs inventory and ownership.

• Media storage and transport concepts.

• Data at rest.

• Data in transit.

• Why encryption does not replace access control or key management.

• What data remanence is.

• Why deletion does not equal sanitization.

• Why NIST SP 800-88 Rev. 2 is now the current sanitization publication.

• What Clear means.

• What Purge means.

• What Destroy means.

• Which sanitization methods may preserve media usability.

• Why Destroy does not.

• What cryptographic erase means.

• Why cryptographic erase depends on encryption/key coverage.

• Why sanitization validation matters.

• Media reuse versus disposal.

• What patch management means.

• Why NIST treats patching as preventive maintenance.

• The patch-management lifecycle.

• Patch versus update versus upgrade conceptually.

• Why accurate asset inventory matters to patching.

• How patch priority should be determined.

• Security risk of not patching.

• Availability risk of patching.

• Why updates should come from trusted sources.

• Why patch testing matters.

• What staged deployment means.

• What a maintenance window is.

• Why active exploitation may justify emergency patching.

• Why emergency patching still requires governance.

• What a rollback plan is.

• Why rollback may restore a vulnerability.

• Why patch verification matters.

• Why patch-console success is not sufficient.

• Why firmware and third-party applications must be considered.

• What End of Life means.

• What End of Support means.

• Why unsupported systems create security risk.

• Why migration/replacement is the preferred long-term solution.

• What compensating controls can do for legacy systems.

• Vulnerability management versus patch management.

• What change management means.

• Configuration management versus change management.

• What a change request is.

• Why business justification is needed.

• What change-impact analysis does.

• Why dependencies matter.

• Why changes require appropriate authorization.

• How separation of duties applies to change management.

• What a standard change represents conceptually.

• What a normal change represents.

• What an emergency change represents.

• Why emergency does not mean uncontrolled.

• Why changes should be tested.

• What an implementation plan contains.

• What a backout plan does.

• Why backups may be required before risky changes.

• Why stakeholders may need notification.

• What post-change verification does.

• What a post-implementation review is.

• Why successful authorized changes require baseline/documentation updates.

• How unauthorized-change monitoring works.

• Why temporary changes need expiration.

• Why high emergency-change rates may indicate broader process problems.

• Why security operations must balance security, change, and availability.

Coming Next

Lesson Twenty-Six: Incident Management and Operational Detection and Prevention

Lesson Twenty-Six will continue CISSP Domain 7 and focus primarily on:

7.6 — Conduct incident management

The current outline includes:

• detection;

• response;

• mitigation;

• reporting;

• recovery;

• remediation;

• lessons learned.

7.7 — Operate and maintain detection and preventive measures

Including:

• firewalls;

• next-generation firewalls;

• web application firewalls;

• network firewalls;

• IDS;

• IPS;

• whitelisting and blacklisting;

• third-party security services;

• sandboxing;

• honeypots;

• honeynets;

• anti-malware;

• machine-learning and AI-based tools.

Lesson Twenty-Six will cover:

• incident-management governance;

• event versus alert versus incident;

• preparation;

• incident detection;

• triage;

• incident classification;

• prioritization;

• severity;

• escalation;

• containment;

• short-term containment;

• long-term containment;

• eradication;

• recovery;

• remediation;

• incident communications;

• legal/privacy coordination;

• regulatory reporting;

• evidence-preserving response;

• lessons learned;

• root-cause analysis;

• playbooks;

• runbooks;

• tabletop exercises;

• firewalls;

• NGFW;

• WAF;

• IDS/IPS;

• allowlisting and denylisting;

• anti-malware;

• EDR concepts;

• sandboxing;

• honeypots/honeynets;

• deceptive controls;

• managed security services;

• AI/ML detection;

• automation risks;

• original SierraTec incident-response models;

• CISSP exam traps;

• knowledge checks;

• scenario-based questions.

The central Lesson Twenty-Six question will be:

When suspicious activity becomes a security incident, how should an organization detect, prioritize, contain, eradicate, recover, communicate, and learn from the event while operating preventive and detective controls that reduce both current and future risk?

Publication and Independence Notice

This lesson is independently developed educational material for the SierraTec Secure CISSP Certification Preparation Course.

CISSP is administered by ISC2. SierraTec Secure's course is independent CISSP certification-preparation material and should not be represented as official ISC2 training unless separately authorized.

Current exam alignment was verified against the official ISC2 CISSP Certification Exam Outline. Objectives 7.3, 7.5, 7.8, and 7.9 currently cover Configuration Management, resource protection, patch/vulnerability management, and change-management processes.

Configuration-management concepts were supplemented with NIST SP 800-128, which remains NIST's final security-focused configuration-management guide, with its current update dated October 2019.

Media protection and sanitization were updated to NIST SP 800-88 Rev. 2, finalized September 26, 2025 and superseding Rev. 1. The current publication retains Clear, Purge, and Destroy as sanitization methods and provides updated enterprise-program and cryptographic-erase guidance.

Patch-management concepts were aligned with NIST SP 800-40 Rev. 4, NIST's final enterprise patch-management planning publication, which treats patching as preventive maintenance and defines the process around identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades.

The SierraTec Secure BASELINE, PATCH, and CHANGE frameworks, diagrams, scenarios, comparison tables, knowledge checks, and practice questions are original instructional material and are not actual, recalled, leaked, or official CISSP examination questions.