RE: [logs] resettable "normal"

toby.kohlenbergat_private

This is one of the major problems when dealing with any sort of 
log analysis- not just raw system logs but IDS data as well. One
of the nicest ways I've seen of dealing with this is statistical
monitoring as implemented in PigSentry for snort. You can specify
the percent change that you want to be notified about and what the
default time period should be. This makes sure you see anything
new (unless you set your notification boundary above 100%) and 
find out when anything changes significantly (based on your definition
of significantly). This is done automatically for every type of alert
seen. Last time I looked it didn't do it on a per source or destination
basis but maybe they've added that since last time I looked.

To the best of my knowledge, (note that disclaimer! There are lots of
products that I haven't seen recently!) none of the major security
monitoring consoles provide this in their current releases though I
know of at least one vendor that will be doing this in their next release.
>:)

All opinions are my own and in no way reflect the views of my employer.

Toby

Toby Kohlenberg, CISSP, GCIH, GCIA
Senior Information Security Analyst
Applied Security Technology Team
Intel Corporate Information Security
503-712-8588  Office & Voicemail
877-497-1696  Pager
"Just because you're paranoid, doesn't mean they're not after you."

PGP Fingerprint:
92E2 E2FC BB8B 98CD 88FA  01A1 6E09 B5BA 9E84 9E70

> -----Original Message-----
> From: list-log-analysisat_private 
> [mailto:list-log-analysisat_private]
> Sent: Tuesday, August 20, 2002 11:50 AM
> To: loganalysisat_private
> Subject: [logs] resettable "normal"
> 
> 
> 
> One of the problems with trying to define normal state is that does
> change, even at one site. An example someone used was Code Red
> attacks. If you're on one of the lucky subnets, this can be a
> continuous noise that you probably want to ignore normally.
> 
> There are certain things we can say are always bad:
> 
>       *) root partition full
>       *) unrecoverable memory error
>       *) pgsql not running on main PostGRESQL server
>       etc.
> 
> Those are pretty easy to come up with and alarm on. The tricky part is
> noticing *changes* and deciding which changes are worth worrying
> about. If I normally get 200 ssh probes an hour and I suddenly go down
> to 20, what happened? If the number of incoming HTTP requests triples
> in 20 minutes, what happened?
> 
> Part of why I like the idea of having a set of ground rules for
> quickly coming up with normal is that I can then redo that process to
> reset normal fairly inexpensively. Having something that recorded the
> rules and let me do diffs of previous normal states would be a neat
> bonus.
> _______________________________________________
> LogAnalysis mailing list
> LogAnalysisat_private
> https://lists.shmoo.com/mailman/listinfo/loganalysis
> 
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
https://lists.shmoo.com/mailman/listinfo/loganalysis