Review and Clean Up Unused Firewall Rules Quarterly

Firewall rule bases are critical security controls, yet they often accrue bloat over time. Unused, outdated, or redundant rules can degrade performance,…

Firewall rule bases are critical security controls, yet they often accrue bloat over time. Unused, outdated, or redundant rules can degrade performance, increase complexity, and, most importantly, expand the attack surface by permitting traffic flows that are no longer necessary or secure. Regular, systematic cleanup of firewall policies is an essential operational practice for maintaining a robust security posture and an efficient network.

The Case for Regular Firewall Rule Review

As networks evolve, applications are decommissioned, IP addresses change, and business requirements shift. Each change potentially leaves behind obsolete firewall rules. While individual stale rules might seem harmless, their cumulative effect can be significant:

• Increased Attack Surface: An unused rule permitting traffic to a server that no longer exists, or an old application that has been replaced, creates a vulnerability. If an attacker gains control of a system within the allowed source, they can exploit the old rule to traverse the network.
• Performance Degradation: Firewalls process rules sequentially, or at least attempt to find the first matching rule. A large, unoptimized rule set increases the processing overhead for every packet, potentially impacting throughput and latency. While modern firewalls employ fast path technologies and optimized rule lookups, an excessively large and poorly ordered rule base will still incur overhead.
• Configuration Complexity & Error Risk: A cluttered rule base is harder to audit, troubleshoot, and manage. Engineers may inadvertently create redundant rules or misconfigure new ones due to difficulty navigating an overly complex policy.
• Compliance Challenges: Regulatory frameworks like PCI DSS, HIPAA, and GDPR often require strict control over network access. Demonstrating a clean, auditable, and purposeful rule set is crucial during security audits. Unjustified rules are a red flag.

Leveraging Hit Counters and Last-Hit Timestamps

Modern Next-Generation Firewalls (NGFWs) provide robust mechanisms to track rule usage. This is the cornerstone of any effective cleanup strategy. Enable hit counters on all rules as a standard practice from deployment.

Palo Alto Networks PAN-OS (v9.x - v10.x)

Palo Alto Networks firewalls automatically track hit counts and last-hit timestamps for security policies. This data is visible in the GUI and accessible via CLI or API.

# To view hit count and last hit for a specific rule
admin@PA-220> show running security-policy rule-name "WEB_to_DB_Access"

# To export all security rules with hit count information
# This command provides a lot of detail, including hit count.
admin@PA-220> show running security-policy | match "rule|hit-count"

# For more structured output, consider exporting via API or management platform (Panorama)
# An API call could involve retrieving security rules and their associated statistics.

In the GUI, navigate to Policies > Security. The 'Hits' column will display the total hits, and hovering over it often shows the 'Last Hit' timestamp. You can sort by this column.

FortiGate FortiOS (v6.x - v7.x)

FortiGates also track rule usage. Ensure logging is enabled for policies to capture hit data effectively.

# To view rule hit counts
FortiGate # diagnose firewall iprope list 100000 | grep -A 5 "rule_id" | grep "hit"

# To list all firewall policies with hit count, useful for scripting:
FortiGate # get firewall policy
# The output for each policy will include "hit: XXXXXXXXXX (last_hit 2023-10-26 14:30:00)"

In the GUI, go to Policy & Objects > Firewall Policy. You can enable the 'Hits' and 'Last Used' columns by right-clicking on the table header.

Cisco Firepower Threat Defense (FTD) (v6.x - v7.x)

Cisco FTD, managed by Firepower Management Center (FMC), tracks rule hits. This information is typically viewed within the FMC GUI.

# While FTD CLI is more limited for policy viewing, you can check connection events.
# Policy hit counts are primarily an FMC feature.
firepower# show access-list
# This will show ACLs, but not direct hit counts per rule as easily as other platforms.
# For FTD, rely on FMC GUI or API.

In FMC, navigate to Policies > Access Control. Select the relevant access control policy. On the 'Rules' tab, ensure 'Hit Counts' is enabled (it usually is by default). The 'Hit Count' column will display the number of hits. The 'Last Hit' timestamp might require looking at connection events or reports tied to specific rules.

The 90-Day Zero-Hit Strategy

Establish a policy that identifies rules with zero hits in the last 90 days. The 90-day window is generally sufficient to account for quarterly business processes, patch cycles, or infrequently used backup systems. Adjust this window based on specific business needs (e.g., 180 days for annual processes).

Workflow for Cleanup:

1. Identify Candidates: Export or filter firewall policies to find all rules with a "last hit" timestamp older than 90 days, or a total hit count of zero.
2. Categorize and Prioritize: Group these rules. Some might be obviously obsolete (e.g., pointing to old IP ranges, decommissioned applications). Others might require deeper investigation.
3. Stakeholder Validation: For each candidate rule, trace back to its original change request, ticket, or documentation. Contact the original requestor or the current responsible department/owner. Ask specific questions:
   • "Is this rule still required?"
   • "What application or service does it support?"
   • "When was it last used, or when do you expect it to be used next?"
   • "Can we disable this rule for a probationary period?"

   This step is crucial and often the most time-consuming. Lack of ownership or outdated documentation will extend this phase.

4. Probationary Disabling: If a rule is no longer needed, do NOT immediately delete it. Disable the rule for a probationary period (e.g., 30 days). This allows for a safety net. If an application breaks, re-enabling a disabled rule is far faster and less impactful than recreating a deleted one. Document the disablement in your change management system.
5. Final Deletion: After the probationary period, if no issues have been reported, proceed with deleting the rule. Document this deletion.

Example Rule Identification (FortiGate CLI pseudo-command for automation):

# This is a conceptual script, as direct last_hit filtering in CLI 'get' is limited.
# Most effective way is to parse 'get firewall policy' output or use API.

# Example for parsing 'get firewall policy' output in a script:
# (Assuming current date is 2024-01-20 for 90-day lookback)
# last_hit_threshold_seconds = (time.time() - 90*24*60*60)

# for policy in fortigate_api.get_all_policies():
#    last_hit_str = policy['last_hit']  # e.g., "2023-09-01 10:00:00"
#    last_hit_datetime = datetime.strptime(last_hit_str, "%Y-%m-%d %H:%M:%S")
#    if last_hit_datetime.timestamp() < last_hit_threshold_seconds:
#        print(f"Policy {policy['name']} (ID: {policy['policyid']}) is a candidate for review.")

For Palo Alto Networks, Panorama (the central management platform) offers more advanced reporting and filtering capabilities to identify stale rules efficiently.

Documentation and Audit Trail

Maintain a meticulous record of each cleanup pass. This is "auditor gold" because it demonstrates proactive security management. Create a recurring change ticket (e.g., "Quarterly Firewall Rule Cleanup - Q1 2024"). Within this ticket, link to or embed:

• The list of identified candidate rules.
• Correspondence or meeting notes from stakeholder validation.
• Dates of disablement and deletion.
• Any exceptions or rules that were found to be legitimate despite low hit counts (e.g., disaster recovery paths, seasonal access).

A simple spreadsheet can track this for each rule:

Common Pitfalls and Troubleshooting

• Incomplete Hit Counter Data: Ensure logging profiles associated with your firewall rules are configured to capture session start/end events, which contribute to hit counts. If rules were created before hit tracking was enabled, their data might be unreliable.
• Overly Aggressive Deletion: Never delete a rule without validation, especially if the original requestor cannot be reached. Disabling first is a critical safeguard.
• Seasonal or Infrequent Usage: Some rules legitimately have low or zero hits for extended periods (e.g., annual audit access, disaster recovery paths, quarterly reporting systems). This highlights the need for stakeholder validation beyond just hit count numbers.
• Shadow Rules: An older, more general rule higher in the policy list might be "shadowing" a newer, more specific rule lower down, causing the specific rule to never get hits. Firewall analysis tools can help identify these.
• Unresponsive Stakeholders: This is the most common roadblock. Implement a process for unconfirmed rules, e.g., after N attempts to contact the owner, disable the rule for a longer probationary period (e.g., 60-90 days), with clear communication that lack of response will lead to deletion.
• No Centralized Documentation: If original rule justifications are not centrally stored (e.g., in a CMDB or ticketing system), tracing ownership and purpose becomes extremely difficult. Start enforcing documentation standards for all new rule requests immediately.