Every security architecture diagram shows firewalls at network boundaries, controlling traffic between zones. Security assessments document firewall rules and confirm they align with policy. Compliance reports attest that network segmentation is in place. Yet when breaches occur, post-incident analysis frequently reveals that firewall configurations did not provide the protection assumed. Attackers moved laterally through supposed segmentation boundaries. Rules intended to be temporary became permanent. Any-to-any rules added for troubleshooting were never removed. The gap between what organisations believe their firewalls are doing and what they actually permit is one of the most common - a nd most dangerous - security blind spots.
How Rule Sprawl Develops
Firewall rule sprawl develops incrementally through individually reasonable decisions that collectively create complexity no one intended. A new application requires connectivity, so rules are added. A troubleshooting session requires temporarily opening access, but the closure ticket gets lost. A firewall migration carries over legacy rules that no one remembers the purpose of. Organisational changes mean the people who created rules no longer work there, and documentation was never adequate. Over years, enterprise firewalls accumulate thousands of rules. Many are redundant - superseded by later rules or rendered unnecessary by infrastructure changes. Many are overly permissive - specifying broader access than actually required because defining precise requirements was difficult. Some are orphaned - the systems or applications they supported no longer exist. Without regular review and cleanup, rule bases become archaeological records of every network change over the firewall's lifetime, with layers of sediment obscuring the current security posture.
Documentation Drift
Even when change management processes exist, documentation often drifts from actual configuration. Rule descriptions may not accurately reflect current purpose. Network diagrams show intended architecture rather than actual implementation. Compliance evidence documents what was configured at assessment time rather than current state. This drift occurs because maintaining accurate documentation requires continuous effort, while the consequences of documentation gaps are not immediately apparent. Teams under pressure to deliver projects focus on making things work rather than updating diagrams. Knowledge exists in the heads of experienced engineers rather than in documented form. When those engineers leave, institutional knowledge leaves with them. The result is that the documentation organisations rely on for security decisions - a rchitecture diagrams, firewall rule matrices, compliance evidence - may bear limited resemblance to actual network configuration. Decisions made based on this documentation may be fundamentally flawed, assuming security controls exist that do not.
Compliance Versus Security
Compliance frameworks typically assess firewall configuration at a point in time against documented requirements. If the firewall is configured as documented and the documentation reflects policy, the control passes. This approach misses several failure modes: documentation that does not reflect actual intent, configurations that drift after assessment, and rules that comply with documented policy but violate security principles not captured in documentation. A firewall rule base can be fully compliant with documented policy while being catastrophically insecure. If the policy permits broad access that should not exist, compliance with that policy is not a security achievement. If compliance assessments rely on documentation that does not reflect actual configuration, passing the assessment means nothing. Organisations that treat compliance as synonymous with security fall into this trap. The compliance assessment provides false assurance that firewall controls are effective, while actual configuration allows far more access than anyone intended or realised.
Closing the Gap
Addressing the gap between intended and actual firewall state requires both technical and process improvements. Traffic flow analysis provides ground truth about what traffic actually traverses the firewall, revealing rules that are never matched (candidates for removal) and traffic that matches overly broad rules (candidates for tightening). Regular rule review processes should examine not just whether rules comply with documentation, but whether the rules and documentation reflect current operational requirements and security principles. Automation can help maintain consistency between policy, documentation, and configuration. Policy-as-code approaches define intended security policy in machine-readable formats that can be automatically validated against actual configuration. Configuration management tools can detect drift from approved baselines and alert or remediate automatically. Zero-trust approaches reduce reliance on firewall rules by implementing access control closer to applications. When access decisions are made based on identity and context at the application layer, the consequences of permissive network rules are reduced. Firewalls become one layer of defence rather than the primary control.
Conclusion
Firewall configurations frequently diverge from intended security policy through rule sprawl, documentation drift, and the gap between compliance and security. Organisations should assume this drift exists in their environments and invest in discovering actual state through traffic analysis and configuration review. Closing the gap requires ongoing process discipline, automation support, and potentially architectural changes that reduce dependence on network-level controls. The first step is acknowledging that the firewall rules are probably lying - what you think they permit and what they actually permit are unlikely to match.
