Raffy, As it is Syslog the PIX has the traditional severity levels. I've found that 0-7 is better reduced to three bins. Again, this is my own personal interpretation. I don't read tea leaves but i do look at Firewall logs. I think that most device vendors have been trying to respond to customers requests for instrumentation in the log. So we have devices that say "I see an X attack". Great, we've hard coded known attacks! What we need is to have the tools so that we can put together lower level reports or primitives from a variety of devices. Clearly this isn't going to be for everyone (yet). But recall that covered wagons had -no- gauges. The early automobiles (1915) had two gauges; a speedometer and a tachometer. By the 1950s they have five. The computer in my 2003 auto checks over 100 different readings (but it doesn't show me 100 gauges). Right now I think we are at the point where we are just breaking away from wanting to look at all the gauges. Liberty for All, Brian At 09:57 AM 10/27/2003 -0800, Raffael Marty wrote: ><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. 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 : Mon Oct 27 2003 - 10:44:41 PST