Re: [logs] Syslog payload format

From: marc (marcat_private)
Date: Fri Jan 03 2003 - 14:20:37 PST

  • Next message: Harry Hoffman: "Re: [logs] swatchrc file"

    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
    



    This archive was generated by hypermail 2b30 : Fri Jan 03 2003 - 18:48:46 PST