Re: Firewall Log Analysis - Computer vs. Human

[Kevin <kkadow () gmail com>]

Another approach is to look at what are the things that a computer can
do a lot better than a human?

Computers don't get bored, nor do they get tired of the sentinel that
continually "cries wolf" and just start ignoring future alarms.  Software
can exactly count the rate of connections or other events, and track
trends in these rates over very short of very long time periods.


On 7/5/05, Adrian Grigorof <adi () grigorof com> wrote:
> 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!".

This type of "event correlation" is definitely something that can be (has been?)
written into a program. 


> Or for example, instead of saying IP 123.123.123.123 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).

Better yet, if your logs are _really_ complete, the analyzer could look back
through the history of TCP connections, determine that port 8543 was
recently used as the local source of a connection out towards port 80 of
the host 123.123.123.123,  and  determine that it is safe to ignore a stray
ACK/RST packet from that host, within a reasonable window.

I've found in log analysis that it's usually not difficult to write a program to
summarize and strip out the "noise", so the human analyst can concentrate
on the unusual events;  not just denied attempts, but also permitted actions
where the connection rate or throughput is significantly higher or lower than
the baseline, or the sources and destination (or pattern of src/dst) differ
from the norm, sort of like 'traffic analysis" in the old school spycraft sense.


> Now, the question is, what are the things (in your opinion) that only a
> human can do?

A human can interpret a sequence of seemingly random actions and make
a good guess as to the existence and intent of the human on the other end.

Beyond that, humans are hardwired for pattern recognition (sometimes too
well, seeing patterns where none actually exist).

One way to look at event analysis is to approach it like the "machine vision"
problem -- it's really difficult to write software that recognizes objects in a
cluttered visual field, much less to approach the ability of a person in
that regard.  That doesn't stop programmers from writing software to do
edge detection and image enhancement, or video motion alarm detection
software for CCTV security systems.

Kevin Kadow
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards