The perennial struggle with firewall logging is a fascinating case study in how well-intentioned "best practices" can actively undermine security posture. We are often told, in vendor whitepapers and certification courses, to log everything. This is presented as a foundational principle. I contend it is a primary cause of operational blindness. The problem isn't a *lack* of data; it’s a critical failure in data *design* and *signal-to-noise ratio*. We build vast, undifferentiated log lakes where critical events drown in a sea of permitted traffic and routine noise.
A pragmatic logging strategy must begin with a ruthless, policy-driven hierarchy. Not all logs are created equal, and your logging level must be inversely proportional to the rule's security criticality. The default stance of logging all denies and permits is intellectually lazy. Consider this structured approach:
* **Tier 1 (Full Detail):** Logging for any rule that enforces a positive security model (e.g., explicit allows to critical servers) or covers high-risk zones (DMZ, PCI segment). Here, you need source/destination IP, port, protocol, interface, byte count, and most importantly, the **matched rule ID**. This is your forensic layer.
* **Tier 2 (Session Start/Stop):** For broader internal segmentation or user-subnet rules. Logging session establishment and termination is sufficient for compliance and trend analysis without the volumetric overhead of every packet.
* **Tier 3 (No Logging):** Explicitly disable logging for low-risk, high-volume traffic. This includes outbound internet access for common ports (80, 443) from user subnets. The denial of "no logging" is a conscious architectural decision, not an omission.
The technical implementation is key. Generic syslog forwarding of everything to a SIEM is a recipe for cost overrun and alert fatigue. You must leverage the firewall's native capabilities to pre-filter and categorize *before* export. For example, on a platform like Palo Alto Networks, you should be using Log Forwarding profiles to segregate Threat, Traffic, and System logs onto distinct SIEM ingestion pipelines. A crude example of a more targeted filter:
```
# Conceptual filter for a critical allow rule (Tier 1)
# Forward ONLY logs for this specific rule to the "Forensic" SIEM destination.
filter {
(rule eq "Allow-DB-Admins-to-PCI-Servers")
and (action eq allow)
}
destination = siem-forensic.prod.local:514
```
Furthermore, we must challenge the dogma of infinite retention. Raw firewall flow logs have a sharply decaying investigative value. The pragmatic practice is a two-tiered retention model: 30-90 days of hot storage for active investigation, followed by 12 months of aggregated, summarized data (e.g., daily top-talker reports, threat count by severity) in cold storage for historical baselining. Storing seven years of raw packet flows is an auditor's fantasy, not a security control.
The ultimate goal is to make your log data *queriable* and *actionable*. If your team cannot, within minutes, answer "show me all successful authentications to this firewall from external IPs in the last 48 hours" or "correlate these malware alerts with outbound traffic to new destinations," then you have a data management failure, not a logging one. We've migrated enough legacy rule sets to see that the bloat originates from a fear of missing something, which ironically ensures you miss everything.
Plan for failure.
James K.