I was watching a video from Cloud Passage earlier today about their new Beta for Windows Firewall management: Halo for Windows.  I don’t mean to take anything away from their work and I think it is a good new offering.  But something jumped out at me near the end of the video that the administrator in the video only chose to log “drops”.  Why just the dropped traffic?

I hear this fairly frequently from people that choose to only log drop traffic, since it represent the “bad” traffic and they can send these logs to their SIEM to get alerts on these dropped connections.  Particularly when performance of logging is a concern and administrators want to reduce the performance impact by reducing their logging, they will turn logging off on highly utilized rules where they *know* what traffic is flowing through those rules.  But, they continue to log ALL their dropped traffic.  This is completely wrong.

Logging dropped packets does two positive things for you:

  1. It allows you to verify your technology is actually working (confirming that the millions of dollars you spent of your firewall is actually doing something)
  2. Identify attacks that failed

I don’t dismiss there is some value in #2, to build up a repository of threats.  And, it can aid in discovering malware inside your network and a few other good uses. For this reason, I still strongly encourage logging many drop rules. But remember, this traffic FAILED.  The preventative technology (firewall, IPS, etc) succeeded.  As for the first case, if you don’t trust the technology, don’t buy it.  And certainly don’t use this count like a scoreboard of security success.  The fact that you successfully blocked traffic is not proof of security…no matter how many things you drop.  This is not a security success metric!

Instead, if you care about security, you should be logging your accepts.  This is the traffic that can represent an actual risk to your organization.  This is the traffic that successfully passes through your security defenses.  There is a ton of value in this data:

  1. Forensics review after a breach is discovered to learn when it started and how long it lasted
  2. Threat alerts when known bad actors are SUCCEEDING in accessing resources in your organization
  3. Anomaly detection when there is an unexpected spike (or drop) in typical traffic behavior

This attitude to log all dropped traffic has been promoted by just about everyone.  Starting with the firewall and IDS vendors, who want to show “value”  by logging dropped traffic (“look, see, I dropped another attack!”).  And it is promoted by standards that say almost nothing about what a firewall policy should or should not do, but will nearly always include a recommendation to “include a clean up rule and LOG it”.  I don’t disagree with logging cleanup rules.  But this is not nearly as important as logging successful access.  In the case of the drop, you already succeeding in thwarting the attack, the log is of little additional value.  In the case of an accept, it is worthy of some additional scrutiny.

My suggestion…log all accepted traffic and reassess which drop rules you want to log.

[NOTE: in the Halo example above, since it is a host-based firewall, there can be limited value in logging the http accepts to the local web server since the web server should be logging connections as well.  This video just happened to get me thinking about this topic this morning.]