<Disclaimer: I work for a security information management (SIM) product company/> Brian, 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. <Vendor/Product-Plug> 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. </Vendor/Product-Plug> > > > - 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 picture! </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 logs. Thanks Raffy -- 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 LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Mon Oct 27 2003 - 10:47:15 PST