Security engineers have been deploying firewall changes and new controls directly to production to respond quickly, bypassing the normal change process, and two outages have resulted. What should the information security manager do?
Select an answer to reveal the explanation.
Short Explanation
Security changes are still changes, and changes break things when nobody's checking. Your change process almost certainly has a fast lane for emergencies, so use it. The trap is assuming that good intentions make a change safe.
Full Explanation
Change management exists to assess impact, obtain appropriate approval, plan testing and rollback, and keep records, so that changes do not disrupt the business. Security changes alter production systems just like any other change and can cause outages, as the two incidents show. The manager should require them to follow the standard process, using the emergency change path where a threat demands rapid action; that path permits fast implementation with expedited approval and retrospective review rather than none at all. Allowing security changes to bypass control because they reduce risk ignores the operational risk they introduce and undermines the credibility of security with the business. Restricting changes to weekends lowers the number of affected users but still lacks impact assessment and approval, delays urgent fixes and does not prevent outages. Documenting changes after deployment improves traceability but provides no prior assessment or authorization, so it would not have prevented either outage. Exam caveat: separation of duties between those who request, approve and implement changes is also a control, and security teams are not exempt from it. Operational check: reconcile production configuration changes against approved change records each week and report unapproved security changes to management as exceptions.