Historian Cutover with Fourteen Undocumented Firewall Rules
A utility is replacing a 20-year-old historian that stores 15 years of operational data. The old historian has 14 firewall rules allowing inbound connections from 40 clients, including business analytics, vendor support, and three engineering workstations. The new historian is installed and tested. During cutover, the old historian must remain online for 30 days for data reconciliation. The firewall rules are undocumented, and several source IPs are dynamic. The change window is four hours on a Saturday. The security team wants to remove all old rules immediately after cutover; the operations team wants to keep them until the 30 days end. A recent audit flagged stale firewall rules and orphaned accounts as a top finding. The firewall has no automatic rule-expiry feature, so the team relies on change tickets and manual review.
1. How would you handle the 30-day overlap to satisfy both operations and security? Be specific about rule lifecycle and monitoring.
Read the worked answer
Do not remove all rules immediately, and do not keep all 14 open for 30 days. Build a temporary documented conduit: identify each of the 40 clients, map source IPs and DNS names, disable rules with no traffic, and consolidate the rest into a least-privilege rule set with logging. Use firewall address groups and DHCP reservations or DNS objects for dynamic clients. Set an expiry date at day 30 and a ticket that triggers manual disable. During the overlap, monitor traffic and alert on new sources. If a client must use the old historian, allow it only to the old historian, not to the new one or the broader network.
2. What lifecycle and audit evidence should be produced for decommissioning?
Read the worked answer
Lifecycle evidence: updated asset inventory showing the old historian decommissioned; data retention and legal hold confirmation; account and certificate removal; firewall rule decommission record with before and after states; backup and archive verification; media sanitization certificate; change record and approval; and a post-decommission scan. Also document the 30-day reconciliation completion and sign-off by operations and security. This closes the audit finding for both stale rules and orphaned accounts.
3. What risks arise from the dynamic source IPs, and how do you mitigate them without blocking legitimate clients?
Read the worked answer
Dynamic source IPs make broad allow rules likely and create spoofing or unintended-access risk. Mitigate by reserving DHCP addresses, using DNS-based firewall objects if supported, or forcing clients through a jump host with MFA. If neither is possible, use temporary rules with logging and alerts on source changes, and review daily. Do not allow any-to-any on the old historian. Residual risk should be accepted in writing for the 30-day period, with an owner and a hard expiry.