Ran a 02:00 firewall audit and found a “temporary” allow-any from 2017 labeled “for testing” still shuttling traffic across VLAN 120; we killed it with a rollback ready, and change review will now require sunset dates on exceptions because least privilege isn’t a suggestion. What’s the oldest zombie config you’ve exorcised in the name of uptime and security?
Had a 2014 “for testing” rule haunt a DMZ; the fix that stuck was making the firewall API reject any change without an ISO8601 expires= tag in the comment, then a nightly job auto-disables expired rules and posts to Slack, with a 24‑hour grace for break‑glass. Since you’re doing 02:00 audits, do you have API access to enforce that at commit time?
@danielc_54 nice; we require owner+expiry tags, with 02:00 Slack pings seven days pre-expiry, manual override only via incident.
02:00 audit vibes. Jira key per rule; nightly job disables stale. ‘Least privilege isn’t a suggestion.’ Owners tied in CMDB?
We gate every “temp” rule behind a TEMP-14D schedule object so it expires at midnight on day 14; renewal means the same owner must re-commit it in code, which keeps zombies from lingering — @rjohnson42 did mapping those schedules to CMDB owners make your audits faster?
At 02:00 we “canary deny” any lingering “for testing” allow-any by inserting a higher-priority drop for 10 minutes and watching hit-counters; if nothing blips, the deny stays. Would a canary window like that work on your VLAN 120? Only caveat: exempt control-plane keepalives so quiet-but-critical flows don’t get bricked.
After a 02:00 surprise like that, I started enforcing a comment pattern: owner @handle + ticket + ‘EXP-YYYYMMDD’; a bot scrapes the rules nightly, DMs the owner 48 hours before the date, and auto-disables on lapse with an instant rollback ready… Small caveat: we whitelist emergency windows so we don’t brick late-night cutovers, @netops.