4.8.2. Operations, Maintenance, and Retirement

💡 First Principle: A system's security posture degrades continuously from the moment it enters production — new vulnerabilities are discovered, configurations drift from baselines, threat actors evolve their techniques, and personnel who understood the original security design move on. Maintaining security requires active, ongoing investment, not just initial implementation.

Change Management and Configuration Management

Change management controls modifications to production systems through a structured process: request → impact assessment (including security review) → testing → authorization (CAB or delegated authority) → implementation → post-implementation review. The security value is threefold: unauthorized changes are detected, all changes are traceable for forensics, and security implications are evaluated before implementation rather than discovered after an incident.

Configuration management maintains systems at their approved security baseline. Automated tools (SCAP scanners, Ansible, DSC, Chef) continuously compare live configurations against the documented baseline and alert on drift. A server where a service was enabled or a firewall rule was modified without a change ticket is a security finding — it may indicate an attacker establishing persistence or an administrator bypassing controls.

The relationship between the two: change management governs how changes happen (process and authorization); configuration management verifies what the current state is (continuous compliance with baseline).

Patch Management Lifecycle

Patch management is the operational embodiment of vulnerability management:

1. Identification — Vendor advisories, CVE feeds, vulnerability scan results identify applicable patches
2. Evaluation — Assess criticality (CVSS + asset exposure + EPSS), determine applicability, check for dependencies
3. Testing — Deploy to a representative staging environment; verify functionality, performance, and stability
4. Deployment — Push to production within SLA windows (Critical: days, High: weeks, Medium: monthly, Low: quarterly)
5. Verification — Re-scan patched systems to confirm remediation; verify no regression
6. Documentation — Record patch status for compliance reporting and audit trail

Emergency patching bypasses the normal change management cycle for actively exploited vulnerabilities (CISA KEV listings, zero-days with public exploits). The process still requires documentation and post-implementation review, but authorization is expedited through an Emergency Change Advisory Board (ECAB) rather than waiting for the next scheduled CAB meeting.

System Monitoring and Auditing

Continuous monitoring during operations serves three purposes:

• Security posture maintenance — Detect configuration drift, new vulnerabilities, and expired certificates before they are exploited
• Threat detection — SIEM correlation, UEBA behavioral analytics, and IDS/IPS alerting identify active threats
• Compliance evidence — Audit logs demonstrate that controls operated effectively throughout the reporting period (SOC 2 Type II, PCI DSS quarterly scans, HIPAA audit requirements)

Audit logs must capture: authentication events (successes and failures), authorization decisions, privilege use, account changes, and security policy modifications. Logs must be stored in tamper-evident, centralized storage where attackers who compromise production systems cannot modify them.

End-of-Life Planning and Asset Disposal

System retirement is a security event, not just an operational decommission. The retirement process must address:

Data disposition: All data on the system must be either migrated to a successor system (with verified integrity) or destroyed per the organization's data retention schedule. Data that must be retained for regulatory compliance must be migrated before the system is decommissioned — not discovered after the hardware is recycled.

Media sanitization: NIST SP 800-88 defines three levels:

License and credential termination: Software licenses must be released (to avoid ongoing costs and audit findings), service accounts must be disabled, API keys and certificates must be revoked, and DNS entries must be removed or redirected. Orphaned credentials from retired systems are a persistent attack vector — an attacker who finds a still-valid API key for a "decommissioned" system that was only powered off (not properly retired) may discover the key still authenticates to backend services.

Documentation: The retirement record must include: what data existed on the system, where it was migrated or how it was destroyed, certification of media sanitization, confirmation of credential revocation, and the date the system was formally removed from the asset inventory. This documentation protects the organization during audits and legal discovery.

⚠️ Exam Trap: "Deleting files" is NOT media sanitization. Standard file deletion removes the directory entry but leaves the data intact on the storage medium — recoverable with forensic tools. The exam tests whether you know the difference between deletion (insufficient), clearing (overwrite — protects against casual recovery), purging (cryptographic erase or degaussing — protects against lab recovery), and destruction (physical — protects against any recovery). For media leaving the organization, purging is the minimum standard.

Reflection Question: A financial institution decommissions a database server that processed credit card transactions for 8 years. The server has two SSDs in a RAID configuration, a 3-year-old backup tape in off-site storage, and replicated data in a disaster recovery site. Describe the complete data disposition process, including which NIST 800-88 sanitization level applies to each medium and why.