Rule review cadence — the schedule that keeps the ruleset honest · OPNsense

A firewall ruleset is not static. Every change adds rules; every incident adds aliases; every refactor leaves residue. Without a deliberate review cadence, the ruleset accumulates rules that no one can explain, aliases that no one uses, and exceptions that no one tracks. The review cadence is the schedule that prevents the accumulation.

This lesson covers the four reviews in a production cadence: weekly operational, monthly hygiene, quarterly security, annual compliance. What each review looks for, who attends, what evidence each review produces.

The four reviews

The four reviews differ in frequency, scope, and audience. The cadence is not four identical reviews at different intervals; it is four distinct reviews with distinct purposes.

Weekly operational review

Frequency: weekly. Duration: 30-60 minutes. Audience: the on-call operator, the firewall lead.

The weekly review looks at:

Changes from the past week. What was changed, by whom, with what approval. The review reads the change tickets and confirms each change is documented and verified.
Incidents from the past week. What incidents occurred, which rules were involved, whether the rules behaved as intended.
Anomalies from the past week. Log lines that look unusual, alerts that fired, state-table growth, traffic spikes.

The weekly review produces a one-page summary: changes, incidents, anomalies, action items. The summary is the audit trail for the week; the next incident investigation has the context.

Monthly hygiene review

Frequency: monthly. Duration: 2-4 hours. Audience: the firewall lead, a senior operator, optionally a security engineer.

The monthly review looks at:

Rule counts. Total rules, rules per interface, rules per category. Trends over the month. A growing count without a corresponding growth in traffic is a sign of rot.
Alias utilisation. Which aliases are used by which rules; which aliases are unused. An unused alias is a candidate for removal.
Dead rules. Rules that have not matched in the past 30 days. A dead rule is a candidate for review (and possibly removal).
Duplicate rules. Rules that match the same traffic pattern with different actions. One is shadowing the other.
Expired rules. Rules with a schedule that has expired, rules tied to a temporary incident that has been resolved.

The monthly review produces a list of candidate actions: rules to remove, aliases to clean up, duplicates to merge, expired rules to archive.

Read-only / SafeRule counts and interface distribution— `pfctl -s rules | wc -l` is the total rule count. The awk pipeline groups rules by interface (the 5th token in the compiled ruleset) and counts. The output shows which interfaces carry the most rules — a high count on a single interface is a candidate for hygiene review. A growing rule count without a corresponding traffic growth is a sign of rot.

$ pfctl -s rules | wc -l && pfctl -s rules | awk '{print $5}' | sort | uniq -c | sort -rn | head -10

847
443 on igb0
212 on igb1
96 on igb2
54 on igb3
21 on enc0
14 on igb0_vlan10
7 on lo0

Illustrative output

Quarterly security review

Frequency: quarterly. Duration: 4-8 hours. Audience: the firewall lead, a security engineer, optionally an external auditor.

The quarterly review looks at:

Rule posture. Default-deny vs default-allow. Floating rules vs interface rules. Aliases that bypass the policy. The review checks that the ruleset enforces the documented security policy.
Source/destination hygiene. Rules with overly broad sources (any, 0.0.0.0/0) or destinations. Rules with internal RFC1918 sources on the WAN interface. Rules with destinations that have not been used in the past 90 days.
Logging posture. Which rules log, which rules do not. The review checks that high-risk rules log and that log destinations are configured.
Anti-spoofing. Rules on the WAN interface that block spoofed sources. Bogon blocking. Private-range blocking on the WAN interface.
Compliance posture. For regulated environments, the ruleset compared against the compliance baseline. PCI-DSS, HIPAA, SOC2 controls relevant to firewall policy.

The quarterly review produces a security posture report. The report is a section of the broader security review; the firewall portion is the ruleset analysis.

Annual compliance review

Frequency: annually. Duration: 1-2 days. Audience: the firewall lead, the security team, the compliance team, optionally an external auditor.

The annual review is the deepest review. It looks at:

Compliance baseline. PCI-DSS Requirement 1 (network security controls), HIPAA Security Rule (§164.312(e)(1)), SOC 2 CC6.6, NIST 800-41. The review checks each control against the ruleset.
Change management audit. Every change in the past year. Was each change documented? Approved? Verified? Rolled back when necessary?
Incident retrospective. Every firewall incident in the past year. What was the root cause? What rule changes followed? Are the follow-ups still in place?
Capacity review. State-table sizing, log retention, alias growth. Is the firewall still right-sized for the estate?
Architecture review. Is the ruleset still aligned with the network architecture? Have there been changes (new VLANs, new VPNs, new services) that the ruleset has not absorbed?

The annual review produces a compliance report. The report is the auditor’s evidence that the firewall estate is under control.

Recognising that a review is overdue

The ruleset that needs a review shows signs:

The operator cannot explain a rule. When the on-call operator is asked “what does this rule do?” and cannot answer, the ruleset has drifted past documentation.
The change log is missing entries. When the operator searches the change log for a recent change and finds no entry, the change was undocumented.
Aliases have grown without review. When the alias list has 200 entries and no one can name the owner of half of them, the aliases have rotted.
State-table entries exist for rules that should not match. When pfctl -s state shows flows against rules that should not be in the ruleset, the ruleset and reality have diverged.
Compliance evidence is missing. When the auditor asks for evidence of the last quarterly review and the team cannot produce it, the cadence has lapsed.

These signs are the operator’s early warning. A firewall that exhibits any of them needs an unscheduled review, plus a return to the cadence.

How rule counts reveal rot

Rule count alone is not a sign of rot — a growing ruleset that matches growing traffic is healthy. The rot appears when the ratio of rules to traffic grows, or when the operator cannot explain the difference between this month’s rule count and last month’s.

The ruleset grows for three reasons:

New rules for new services. A new application gets a rule, an alias, possibly a NAT entry. This growth is justified.
Exception rules that were never removed. A rule added for an incident that has since resolved, a rule added for a temporary service that is no longer running, an exception that became the default. This growth is rot.
Duplicate rules from incomplete refactors. A rule added for a refactor that was never completed, a new rule next to an old rule that does the same thing. This growth is rot.

The hygiene review distinguishes the three. The justified growth is kept; the rot is removed.

Summary

Four reviews at four cadences: weekly operational, monthly hygiene, quarterly security, annual compliance. Each has a distinct audience, duration, and output.
The weekly review produces a one-page summary. The monthly review produces a candidate-action list. The quarterly review produces a security posture report. The annual review produces a compliance report.
Signs that a review is overdue: unexplained rules, missing change-log entries, aliases without owners, state-table entries for rules that should not match, missing compliance evidence.
The review cadence is what keeps the ruleset honest. A firewall without a cadence is a firewall being trusted on hope.