[logs] Log Analysis -- Best Practice

[harshad.mengle at wipro.com]

Hi All:

I am looking for Best Practice information for Log Analysis. Is there
anyone who can help me out? 

Regards,

Harshad
 

-----Original Message-----
From: loganalysis-bounces at loganalysis.org
[mailto:loganalysis-bounces at loganalysis.org] On Behalf Of Fenwick, Wynn
Sent: Monday, May 28, 2007 11:29 PM
To: loganalysis at loganalysis.org
Subject: [logs] SIM solution - Objectives ? (Firewall logging)

I love it when people take this logic and extend it such that a
switching firewall is asked to log 100+ bytes of data per session.  The
firewalls tend to work really well then. 

If you never reconcile the bank account, why keep all those little
receipts from Starbucks?

Should the firewall continues to work nicely because it does something
smart like roll up the logs a bit, issue periodic summaries (ie: log
connections start and end), then you are back to logging for the sake of
piling it up. 

The mistake people commonly make is that if we capture it, aggregate it,
and archive it, then "someone" will look at it. Even if someone isn't
"no-one", then the someone must knows a "high alert" when they see it.
After all it takes a highly-alertable person to know a high alert. It is
rare to find these people willing to sift through logs all day (or
worse, all night)

So I bring this back full circle.

Would it not be better to say that we are going to take X effort and
spend it looking at a set of N rolled-up events and action owners to fix
stuff. Yes, it's asymptotic, imperfect, and more art than science, but
it has precedents in many other areas and will likely meet "good enough"
standards. 

You will never find a standing operating procedure that says "only watch
for the 'important laws' because we only can enforce that 1%". It will
invalidate the other 99% of laws, and we'd never want anyone to think
that...

If the standards are unachievable, the elbow on the business curve will
be hit, and the business people will need to solve the problem they
created by overinterpreting some of these standards and overscoping
them. The model or the ability to execute it?

W


-----Original Message-----
From: loganalysis-bounces at loganalysis.org
[mailto:loganalysis-bounces at loganalysis.org] On Behalf Of Marcus J.
Ranum
Sent: Sunday, May 27, 2007 5:03 PM
To: Paul Melson; Ron Gula
Cc: loganalysis at loganalysis.org
Subject: Re: [logs] SIM solution - Objectives ? (Firewall logging)

Paul Melson wrote:
>Logging 'deny' messages and not 'accept' messages from a firewall is, 
>in my opinion, a very outdated way of looking at firewall log data.

Minor nit - I think you meant to write "stupid" not "outdated."
As far back as I can remember (and that's a long way!) some of us have
been saying that permit log entries are more important than deny. In
fact, the first codebase of my first firewall didn't even bother logging
denys because, at the time I felt that a deny log message only meant
"the firewall is working."

mjr.

_______________________________________________
LogAnalysis mailing list
LogAnalysis at loganalysis.org
http://www.loganalysis.org/mailman/listinfo/loganalysis

_______________________________________________
LogAnalysis mailing list
LogAnalysis at loganalysis.org
http://www.loganalysis.org/mailman/listinfo/loganalysis


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
 
www.wipro.com