A change to open a database port from the Internet is headed to the city’s change advisory board without security review. Why should security participate in that CAB process?
Select an answer to reveal the explanation.
Short Explanation
CAB is where bad ideas get a seatbelt check. Security at the table spots “open that DB to the world” before it ships—not after the scanners scream.
Full Explanation
Change advisory board (CAB) participation by security exists to evaluate risk before a change is approved and implemented. A proposal to open a database port from the Internet is exactly the class of misconfiguration that should be challenged for exposure, authentication, encryption, compensating controls, and business justification while the change is still reversible on paper. Early security representation reduces the chance that a convenient network tweak becomes a public data breach for municipal records.
Security participation that always blocks every change regardless of risk abandons risk-based decision making and destroys CAB credibility. CAB membership does not replace technical testing—governance and testing are complementary. Reviewing changes only after they reach production shifts security into cleanup mode when citizens’ data may already be exposed; preventive review is the point of change control.
Exam caveat: change management is a security operations and software security governance control. Security’s role is risk evaluation and control impact analysis, not reflexive veto or rubber stamp. Internet-exposed database services are a classic high-risk pattern the exam expects you to catch pre-implementation.
Operational check: require security sign-off criteria on CAB packets for externally exposed services, verify test evidence accompanies the request, and spot-check production afterward to confirm the implemented change matches what was approved—no silent port openings.