Re: [logs] Syslog payload format

marcat_private

You wrote:
> What I'm missing the most in your API is the semantics: as long as the
> "label" ist still a free form text I don't see much of an improvement
> over the current situation. My goal for a syslog replacement/renovation
> is to get "meaning" into the logs; formatting for storage or display is
> a secondary issue as long as the information is there in any parseable
> format.

Hi

The proposal is an attempt to get something of a least common denominator
between the API I have implemented (rather larger), what Marcus has
been proposing and what Balazs is planning to implement. I still think
that this would be useful.

I have my own ideas about semantics: I think there are
three levels of logging

  1 The easy stuff common to everything. Time, id, etc.

  2 The domain of the application programmer. If somebody
    is coding an httpd, let them log urls, status codes, etc.
    With a bit of luck this can be standardised for popular
    application types, eg the common log format for HTTP servers.

  3 A higher level abstraction, or rather several. This is
    what Tina is always reminding us to focus on and what the Marcus
    and Pauls Logging Data Map seeks to describe. The data map
    is useful. 

    However, my personal opinion is that constructing an automated analysis
    component working on a full semantics is going to be AI-hard.

    So my approach is to think of several security abstractions/models
    and work with those. If you have a recent version of IDS/A 
    installed look in /usr/local/include/idsa_schemes.h

    Some sample models:

      AM - the access control model. A subject does something to
      an object. Events defined in terms of that model report
      three fields, eg:

        .am-1.subject:uid=100 .am-1.action:string="action-read" .am-1.object:file="/etc/passwd"

      SSM - the simple service model. An application tries to get
      some work done. In doing so it enters several states. This
      only involves one field .ssm-1, but its values are defined.
      The full list is given in the include file, but samples
      are "service-start", "service-fail", "work-start", etc.

        .ssm-1:string="service-fail"

      If you download linetd (jade.cs.uct.ac.za/linetd/) you can                      see a subset of that model in action.

    There are several other models, some not in that include file.
    I apologies for the lack of documentation - with a bit 
    of luck a paper will be forthcoming. Note that many events
    are supposed to report data in several domains/abstractions.

    The .something.something is actually starting to look like SNMP,
    though with an IMHO saner transport. The idea is to make the "."
    akin to the root (/) indicating a global namespace, while the other
    fields are local, analogous to files in the current working directory,
    where the current working directory is indicated with the scheme
    field. Technically the fields in [1] should also start with a "."

regards

marc

PS: Sorry for the out of sequence mail. I am currently on dialup.

_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis