This is a discussion on RE: [fw-wiz] Firewall Log Analysis - Computer vs. Human - Firewalls ; Only a human can be pissed when his or her pager goes off at 3am. :-) The rest of the "analysis" of any specific conditions or cases can be done with software because it's based on static or logical conditions. ...
Only a human can be pissed when his or her pager goes off at 3am. :-) The
rest of the "analysis" of any specific conditions or cases can be done with
software because it's based on static or logical conditions. For that
matter, it should be done with software.
Log analysis is a loathesome job if you slog through the same junk day in
and day out. It's also pretty easy to get blinded to subtle anomalies when
you are drowning in logs. Therefore, it makes the most sense to me to use
software to reduce the 'noise' or at least convert it into useful
information (like event counts, event count deltas, event count averages
over time, etc.). The end result should be that any human performing log
analysis should only be looking at individual events that are specifically
identified as significant or are not identified as being insignificant - the
former requiring some sort of action, and the latter requiring at least some
form of additional investigation.
We are trying to develop a log analyzer that would "replicate" a human's
approach to log analysis - by that I mean the fact that a human can
correlate information in the log with other factors (like - "hmm, the log
says that the firewall was restarted at 12:03 PM"... oh, yeah, it was that
UPS failure yesterday around noon). For this particular example, the log
analyzer could say in the report: "12:03 PM - Firewall restarted - Possible
power failure, power disconnection or manual restart" - a bit vague I agree
but it is better than nothing - and in fact, this is what the firewall
admin would go through, right? Thinking, "Why would there be a restart? I
did not restart it.. anything happened at noon? The UPS failure!". Or for
example, instead of saying IP 18.104.22.168 was denied for protocol
TCP/8543 and let the firewall admin worry about it maybe the analyzer should
do a bit of analysis, check the "history", see that this protocol is not
something commonly used, it's not one of the common worms and decide to
report that it is in fact a stray TCP packet caused by Internet latency (TCP
port higher than 1024, not a "known protocol", coming from an IP address
that is typically accessed by internal IPs via HTTP - all this information
is should be obtainable from the logs).
Now, the question is, what are the things (in your opinion) that only a
human can do?
firewall-wizards mailing list