CompTIA Security+ (SY0-801)
Change management process: Security+ change control steps
Change management makes sure every configuration change is requested, recorded, analyzed for security impact, tested and approved before it is made, then verified and closed. A change board approves changes after seeing the impact analysis and test results. Pre-approved changes skip the board, but the documentation, such as the baseline configuration, must still be updated.
The steps in order
NIST SP 800-128 lists the configuration change control steps: request the change, record the request, decide whether the change needs configuration control, analyze its security impact, test it, approve it, implement it, verify it, and close the request.
Testing confirms the impacts found in analysis and may reveal more. Those impacts go to the change board before it approves. A change request is not closed until someone has confirmed the change was deployed without issues, for example with vulnerability scans or a reassessment of affected controls.
The change board and security impact analysis
SP 800-128 calls the change board a Configuration Control Board (CCB): two or more people with the collective authority to review and approve changes to a system. Exam questions often call this group a change advisory board (CAB).
Security impact analysis is done by qualified staff to determine how far a change would affect the system's security posture. It should happen before the change is approved and implemented. The board may require extra controls if a needed change weakens security.
Pre-approved changes, rollback and documentation
An organization can name types of change that are pre-approved, such as vendor security patches, antivirus signature updates and replacing faulty hardware. Those go ahead without board review. SP 800-128 says system documentation may still need updating, such as the system security plan, the baseline configuration and the component inventory.
Change procedures should also cover rollback if problems occur and expedited handling for urgent changes such as critical flaw fixes. Implementing a change includes updating system documentation and notifying stakeholders, especially if service will be interrupted.
Example: a team installs a pre-approved vendor patch on a firewall. No board review is needed, but the firewall's baseline configuration record must be updated to match.
Where the exam catches people
- Believing the board approves first and testing comes later: impact analysis and testing come before approval, and their results go to the board.
- Believing a pre-approved change needs no paperwork: the baseline configuration and other system documents may still need updating.
- Believing a change is finished once installed: it must be verified and the request closed.
- Believing security impact analysis is only done after implementation: it should be done before approval, and again afterwards to confirm the change was made as approved.