RE: [logs] resettable "normal"

From: Kohlenberg, Toby (toby.kohlenbergat_private)
Date: Tue Aug 20 2002 - 22:52:10 PDT

  • Next message: Greg Black: "Re: Re[2]: [logs] Logging: World Domination"

    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
    



    This archive was generated by hypermail 2b30 : Tue Aug 20 2002 - 23:02:16 PDT