NexusSec.Why rule bases decay
No firewall is misconfigured on day one. Decay happens gradually: an urgent request gets a temporary any-any rule at 6pm on a Friday, a project ends but its rules remain, a server is decommissioned and nobody removes its policy, staff change and the reasoning behind rules is lost.
After a few years, a typical rule base contains policies nobody can explain and nobody dares remove. That uncertainty is itself the risk — because the rules permitting an attacker's lateral movement are hiding among them.
What we review
| Area | What we look for |
|---|---|
| Over-permissive rules | any-any policies, broad source or destination ranges, whole-subnet access where a service would do |
| Shadowed rules | Rules never evaluated because an earlier rule already matches — a common source of false confidence |
| Unused rules and objects | Policies with no hit count and objects referencing decommissioned systems |
| Rule order | Whether ordering produces the intended effect and whether performance can be improved |
| Inbound exposure | Services published to the internet, especially management interfaces and remote access |
| Outbound control | Whether outbound traffic is filtered at all — frequently it is not, which aids data exfiltration |
| Segmentation policy | Whether inter-zone rules genuinely restrict movement — see segmentation |
| Security features | Whether IPS is blocking or merely monitoring, whether TLS inspection is enabled, whether logging is on |
| Hardening | Admin access controls, MFA on management, firmware currency, backup of configuration |
What we typically find
- IPS enabled but in detection-only mode — the licence is paid for, the protection is not active. This is remarkably common.
- TLS inspection never configured, meaning the majority of traffic passes uninspected.
- Unrestricted outbound access, so malware communicates freely with command-and-control infrastructure.
- Management interfaces reachable from user networks or, occasionally, the internet.
- Any-any rules that survived years beyond the incident that created them.
- Firmware several versions behind, missing published security fixes.
Our approach
- Configuration collection — export of the rule base, objects, routing and feature configuration.
- Automated analysis — identifying shadowed, redundant, unused and over-permissive rules at scale.
- Manual review — assessing intent and business context, because a broad rule is sometimes legitimate.
- Hit-count analysis — establishing which rules are genuinely in use.
- Hardening review — management access, logging, feature configuration and firmware.
- Prioritised report — grouped into immediate risks, clean-up opportunities and architectural recommendations.
- Optional remediation — we can implement the changes with you in controlled windows.
Platforms we audit
Fortinet FortiGate, Sophos XGS, WatchGuard Firebox, Palo Alto Networks, Check Point, Cisco, and pfSense/OPNsense. Because we deploy across all of these, recommendations are practical for your specific platform rather than generic.
How often
Annually as a baseline, and after major changes such as a network redesign, office move, merger or migration. Organisations with frequent rule changes benefit from a shorter cycle — every six months is reasonable where change volume is high.