Re: [logs] firewall logging and rulesets

From: Brian Ford (brford@private)
Date: Sat Oct 25 2003 - 14:45:24 PDT

  • Next message: Fiamingo, Frank: "RE: [logs] stupid question about facility and level"

    Raffy,
    
    In line.
    
    At 04:12 PM 10/24/2003 -0700, Raffael Marty wrote:
    >Brian,
    >
    >Interesting answers. Some comments of mine inline:
    >
    > > When you said "Host OS messages as applicable"; the way I interpret 
    > that is
    > > there are three buckets into which I throw messages.  Messages that are
    > > issued as part of the normal operation go in one bucket.  Messages that 
    > are
    > > issued irregularly when defined things happen go into another 
    > bucket.   And
    > > then there are messages that signal a problem that go into a "red"
    > > bucket.  So for my three "buckets" I do this:
    >
    >Does the PIX actually indicate these buckets (or similar ones) in the events?
    
    No
    
    >Could I use the event-id ranges for that?
    
    I do this via message ID.  I am in the process of writing this up.
    
    >Or is that a feature which will be added
    >in a future release?
    
    Doubtful.  We're trying to put the features in there so different designs 
    and reporting requirements will be supported.
    
    
    > > - I like to count the normal operations messages and make sure that I
    > > create some baseline (between x-y per hour or y-z per day).  This baseline
    > > is a kind of load gauge for the device.
    >
    >Good point. Now you just need the tool to do this.
    
    Ding, ding, ding! Winner.  Absolutely.  I think we need to ask a bunch of 
    tool vendors to support this.
    
    
    > > - The "irregular" messages usually require correlation with other
    > > conditions or events.  If someone were auditing what I was doing they 
    > would
    > > ask about those.  I should have an explanation.  How often I do that
    > > depends on what I can get away with (audit interval).
    >
    >For this you normally need some more context information; basically the
    >capability to correlate with other event sources!
    
    Yes.  And that is tremendously frustrating since no one seems to do much 
    the same way.  But it is do-able.
    
    
    > > Most of the time I talk to people about this they ask me to tell them 
    > about
    > > "events".    Analyzing log data I can put most people to sleep telling you
    > > about this, that, and the other events.  The challenge here is for someone
    > > to come up with a really good list of events that we should tell everyone
    > > about.  The ICSA Firewall program folks have done a decent job of heading
    > > down that road.
    >
    >I can try to be the "someone to come up with a [really good?] list":
    >Tell me everything the firewall does! That's all I want! Then assign a
    >severity to the events and let me decide which ones I wanna look at.
    >Only if I see all the events, I can draw myself an adequate picture of
    >what is happening across my network.
    
    I think that this is great.  I suggest you need to use the Firewall in the 
    network you operate and others you design. Alot of the work here isn't just 
    listing all the features.  It's how the features are used together to solve 
    various design issues.
    
    
    >A different issue as a remark on the side:
    >
    >I get kind of frustrated with the log formats people use. Including PIX.
    >Why can't you stick to a uniform format? Maybe having a handfull of
    >different formats. Just something that is parseable easily enough?! In
    >the PIX events the source IP is sometimes at the beginning, then in the
    >middle of the event, ... This makes it really hard to parse the events
    >and analyze them! Not that it is not possible, but makes things more
    >time consuming and error prone!
    
    Guilty as charged.
    
     From where I sit something you (all) can do to help fix this is when you 
    find something that isn't right open a TAC case.  That gets the issue into 
    the defect tracking system and in front of the product managers and 
    engineers when rolling up new versions.
    
    
    >         Thanks
    >
    >         - Raffy
    
    Thanks.  I appreciate it.
    
    Liberty for All,
    
    Brian
    
    
    >--
    >
    >Raffael Marty, CISSP
    >Security Engineer                           Content Team @ ArcSight Inc.
    >1309 South Mary Ave.                                 Sunnyvale, CA 94087
    
    
    Brian Ford
    Consulting Engineer, Security & Integrity Specialist
    Office of Strategic Technology Planning
    Cisco Systems Inc.
    http://www.cisco.com/go/safe/
    
    The opinions expressed in this message are those of the author and not 
    necessarily those of Cisco Systems, Inc.
    
    _______________________________________________
    LogAnalysis mailing list
    LogAnalysis@private
    http://lists.shmoo.com/mailman/listinfo/loganalysis
    



    This archive was generated by hypermail 2b30 : Sun Oct 26 2003 - 15:24:05 PST