Frank, >It's also clear that trying to standardise on even that one type of event is >a fairly large piece of work that takes you far from home - including such >issues as how to represent a user ID in various systems. Should that be a >string? A number (e.g. a UNIX UID)? An NT SID? Kerberos principal name? All >of the above? Should a user ID be a part of all events, a standard header >item? What about things like delegation, impersonation and effective user >ids? If a session is created, should the ID of THAT be logged with related >events, or should the analyzer have to infer it? What if there is no >session? And so on... Hhmmmm..... I see where you're coming from. But I think this could be beyond our reach. A full definition of the form and content of a message which we expect to become globally used would require Universal acceptance. Having worked with OSI products in the past I can tell you the Vendor response to anything which threatens their ability to compete ( i.e. anything which allows their competitors a level playing field ) leads to excessive delay and agreement only on things which will not work in practice. ( Remember FTAM? Ever get it to work right? ;-) Would it be better for us to get agreement on a sane format and worry about how to populate the fields for particular systems later? I think this is especially important since there are likely to be people who would desperately like to avoid conforming to any standards not of their own making.... If we can agree a model which is: 1) simple 2) easy to relate to current usage 3) provides a clear logical path for change 4) is easy to analyse ( parses well? ) 5) capable of easy import to a database 6) is "RFCable"/meets Internet standards - "rough consensus and running code" Then I think we will have acheived enough - we just release it and let it find a good home. To achieve nirvana and have everyone using the same values to uniformly populate fields might be easier to do in Open Source and I agree we should attempt to progress it, but I think the more important task will be to develop and publicise the common model. Yes, it will mean more work to get useable filters for non-conformant platforms, but ultimately it is easier to do that than get buy-in from owners of proprietary software. If we try to get buy-in, the effort will get bogged down and deliver nothing soon enough to prevent the field being taken by products with marketing muscle. I feel strongly this would be bad for most people ( your viewpoint may differ if you hold certain shares........ ;-) Regards, tom. __________________________________________________ Security Consultant/Analyst CSC Ph: +61 8 9429 6478 Email: tcleary2at_private ---------------------------------------------------------------------------------------- This email, including any attachments, is intended only for use by the addressee(s) and may contain confidential and/or personal information and may also be the subject of legal privilege. Any personal information contained in this email is not to be used or disclosed for any purpose other than the purpose for which you have received it. If you are not the intended recipient, you must not disclose or use the information contained in it. In this case, please let me know by return email, delete the message permanently from your system and destroy any copies. ---------------------------------------------------------------------------------------- _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Dec 18 2002 - 15:14:10 PST