Policy Drift Detection: How to Catch Unauthorized Firewall Changes Before Auditors Do
Between audits, firewall configurations drift. Emergency rules get added during incidents and never removed. Network objects are modified without change tickets. NAT rules change during troubleshooting sessions. By the time your next compliance assessment arrives, the firewall configuration has diverged from what was approved — and nobody knows exactly how or when. Policy drift detection catches these unauthorized changes before auditors do.
This guide covers what policy drift is, why it matters for compliance, how baseline management works, the 8 types of drift FwChange detects, severity classification, and the 3 resolution workflows for handling drift events.
What Is Policy Drift?
Policy drift is the difference between the approved (baselined) configuration of a firewall and its current running configuration. In a perfect world, every change goes through a formal change management process — requested, reviewed, approved, implemented, and documented. In the real world, changes happen outside the process: emergency access during an incident, a quick fix during a maintenance window that was never documented, a well-intentioned engineer who adds a rule directly on the firewall instead of going through the workflow.
Each of these out-of-band changes creates drift. Individually, they may be minor. Collectively, over months or years, they transform the firewall configuration into something that no longer matches what was reviewed and approved. This is a compliance problem, a security problem, and an operational problem all at once.
Why Drift Matters for Compliance
Every major compliance framework requires controlled change management for network security devices. When an auditor compares your documented change history against the actual firewall configuration and finds discrepancies, those discrepancies become audit findings.
Drift and Compliance Frameworks
- PCI-DSS 4.0: Requirement 1.2.7 mandates review of configurations at least every 6 months. Drift between reviews is a direct finding.
- ISO 27001: Annex A.12.1.2 requires change management procedures. Unauthorized changes violate this control.
- NIS2: Article 21 requires appropriate measures for incident handling and security maintenance. Undetected drift undermines both.
- KRITIS: BSI requirements include documented configuration management. Drift represents undocumented configuration changes.
The auditor does not care why the drift happened. They care that it happened and that you did not detect it. Having a drift detection system that runs continuously demonstrates proactive governance — the opposite of waiting for an auditor to find your problems. For more on PCI-DSS firewall compliance and KRITIS requirements, see our dedicated guides.
Baseline Management
Drift detection starts with a baseline: a snapshot of the approved firewall configuration at a specific point in time. The baseline captures the complete state of the firewall — rules, objects, NAT entries, and system configuration — and marks it as the “known good” state.
Creating a baseline is a deliberate act. You review the current configuration, confirm it matches your approved state, and save it. From that point forward, any deviation from the baseline is drift. Baselines should be updated after approved changes go through your change management process, so the comparison always reflects the latest approved state.
8 Types of Drift
FwChange detects 8 distinct types of configuration drift, covering the full range of changes that can happen on a firewall:
Rule Added
A new firewall rule exists in the current configuration that was not present in the baseline. This could be an emergency rule, an unauthorized addition, or a rule added through a parallel workflow.
Rule Removed
A rule that existed in the baseline is no longer present. Someone deleted it without going through the change process. This can be as dangerous as an unauthorized addition if a critical security rule was removed.
Rule Modified
A rule exists in both baseline and current configuration, but its properties have changed — source, destination, service, action, or other attributes were modified.
Object Added
A new network object (address group, service group) was created. Objects define what rules reference, so new objects may indicate upcoming rule changes.
Object Removed
A network object from the baseline was deleted. If rules still reference it, this could cause policy errors or unintended traffic behavior.
Object Modified
An existing network object was changed — members added or removed from address groups, service definitions altered. This can silently expand or restrict rule scope.
NAT Changed
NAT (Network Address Translation) rules were added, removed, or modified. NAT changes can redirect traffic in ways that bypass security policies.
Config Changed
General system configuration changed — logging settings, interface assignments, routing, or other device-level settings that affect security posture.
Severity Classification
Not all drift is equally urgent. FwChange classifies drift events into 5 severity levels based on the type of change and its potential security impact:
- Critical: Changes that directly impact security — removing deny rules, adding broadly permissive rules, modifying zone boundaries.
- High: Significant unauthorized changes — new rules allowing external access, removal of logging, NAT modifications affecting critical services.
- Medium: Moderate risk changes that need review — rule modifications, object changes that affect rule scope, configuration adjustments.
- Low: Low-risk changes — minor object additions, disabled rule removals, cosmetic changes.
- Info: Informational changes — description updates, comment modifications, non-security configuration changes.
3 Resolution Workflows
When drift is detected, it needs to be resolved. FwChange provides 3 resolution workflows for each drift event:
Approve (Update Baseline)
The change was legitimate but bypassed the normal process. Perhaps it was an emergency fix that needs retroactive documentation. Approving the drift event updates the baseline to include the change and creates a record that the deviation was reviewed and accepted. This is the most common resolution for changes made during incident response.
Ignore
The drift is acknowledged but does not require action or baseline update. This is appropriate for known temporary states — a maintenance window in progress, a planned migration that has not completed, or a configuration that will be updated again soon. The drift event is marked as reviewed but the baseline remains unchanged.
Revert
The change was unauthorized and needs to be reversed. Reverting restores the firewall configuration to match the baseline. This is the appropriate response when someone made an unsanctioned change that was not approved through any process. In practice, revert is used sparingly because it requires confirming that reverting will not break active services.
Automated Detection
Manual drift checks are impractical. By the time you manually compare configurations, the information is already stale. FwChange runs drift detection on an automated schedule — hourly by default — via a cron job that compares the current firewall configuration against the active baseline.
When drift is detected, the system creates drift events with full details: what changed, when it was detected, the severity classification, and the specific differences between baseline and current state. Administrators are notified for high and critical severity events so they can investigate and resolve promptly.
Best Practices
- Create baselines after every approved change window. Keep the baseline current so you are comparing against the latest approved state, not a stale snapshot from months ago.
- Review drift events weekly. Even low-severity drift accumulates. A weekly review prevents drift from building up between audit cycles.
- Document emergency changes retroactively. When emergency rules bypass the normal process, use the approve workflow to document and baseline them. The goal is a complete record, not a perfect process.
- Track drift metrics over time. The number of drift events per firewall per month tells you how well your change management process is working. Rising drift indicates process gaps; falling drift indicates adoption.
- Integrate drift detection with change management. Drift detection is most effective when it is part of your overall governance framework, not a standalone tool. Every drift event should link back to the question: “Why did this change not go through the process?”
Policy drift is inevitable. Unauthorized changes will happen — during incidents, during maintenance, and through human error. The question is not whether drift will occur but whether you will detect it. Automated drift detection with baseline management, severity classification, and resolution workflows gives you the visibility and control that auditors expect and that security operations require.
See How Your Firewall Rules Score
Upload your config and get a free compliance report with shadow rule detection, conflict analysis, and optimization recommendations.
Stay Updated
Get firewall management tips, compliance guides, and product updates.
No spam. Unsubscribe anytime.