Re: [logs] firewall logging and rulesets

From: Raffael Marty (raffael.marty@private)
Date: Mon Oct 27 2003 - 09:57:32 PST

  • Next message: Jason Haar: "Re: [logs] stupid question about facility and level"

    <Disclaimer: I work for a security information management (SIM) product
    Thanks for you extensive answers!
    > >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.
    Why isn't there a field in the message indicating the bucket? Something
    like an event-category or a severity!
    > >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 think I can't quite follow. Logs are there to hold information about
    the status of a device and actions it took. Why isn't it a reporting
    requirement to have those buckets?
    > > > - 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.
    Among other features, that's what we (ArcSight) do in our product. You
    can have so-called datamonitors which observe the amout of data coming
    from a certain device. If the amount of events starts to increase or
    decrease too much, you can be notified or you can take any other action
    you define.
    > > > - 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.
    <Second Vendor/Product-Plug> 
    Well, we are! I think this is where everyone will go in the future! You
    can only understand your network and know what is going on in real-time,
    if you use _all_ your sources of information to help you draw the
    </Second Vendor/Product-Plug> 
    > >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.
    What I wanted to emphasize is that most of the device-vendors just log
    if a packet was dropped or if it was passed. That's just not enough
    information. I would like to have much more information. If you filter
    IP fragments and the packet is dropped as a result of that filter, I
    would like to see that indicated in the logged event. Furhtermore, I
    need to know if someone tries to access the firewall, when it fails
    over, etc. Therefore I really appreciate the extent at which the PIX
    Raffael Marty, CISSP                          raffael.marty@private
    Security Engineer                           Content Team @ ArcSight Inc.
    1309 South Mary Ave.         Sunnyvale, CA 94087          (408) 328 5562
    Raffy's opinions are not necessarily ArcSight's policy.
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Mon Oct 27 2003 - 10:47:15 PST