Re: [logs] Syslog payload format

From: tcleary2at_private
Date: Mon Dec 30 2002 - 19:53:51 PST

  • Next message: Darren Reed: "Re: [logs] Syslog payload format"

    tbird said:
    
    >And (reiterates the moderator, who's getting tired of slogging this dead
    >horse)...
    
    Back to basics: why are we logging? - to catch the bad guys/ establish a 
    "norm" on a system for evidentiary/administrative purposes.
    
    For administrative purposes, beyond a small core of commonality the detail 
    is mostly undefined so it can be moulded to a sites' needs.
    
    What do we need to catch the bad guys? - whatever the Criminal Justice 
    System needs.
    
    For the CJS the main criteria are normally credible proof that:
    
    a) an offence took place
    b) the accused was the offender
    
    Assumptions:
    
    1) The cybercrime was committed without the consent of the victim.
    2) The "common view" of the context of the offence was present ( i.e. the 
    system was properly secured. And yeah, I know standards are kinda hazy 
    right now ;-)
    3) Some harm was caused, for which the victim seeks redress.
    
    Usually, to get a conviction you need to answer the old "Clue" questions - 
    who, what, when, where, how, why.
    
    Who is always going to be difficult, computer or not ( cf. real world 
    identification evidence - line-ups, fingerprints, DNA, retina prints, 
    voice prints blahblahblah )
    
    And if all we can get is an account name which is devoid of context 
    outside the machine/domain in which it was generated and is not tied 1:1 
    with a person, we have a problem. PKI? interesting challenge Govt. or 
    Business doesn't want to fund. Web of trust? Too hard for J. Q. User and 
    thus, not universal == not reliable.
    
    Where - hostname? ip address? MAC address? CPU ID? virtual host url? 
    Corporate Tradename? DLCI number?
    
    This also is context dependant and has few canonical registers to verify 
    that it means anything to someone other than the sysadmin who runs the 
    box.
    
    When - earlier posts have examined this in detail. Not easy to acheive 
    consensus, even in the presence of standards.
    
    What - definitions listed in cybercrime legislation. In my view, they 
    don't compare well with each other OR with previous law. DMCA? remember 
    prohibition?
    
    How - this is why Mitre started the CVE stuff. That has yet to mature into 
    anything useable and may never do so, vendors permitting.
    
    From a Justice system perspective, I think we might be permitted to assume 
    that without a means of proving that the evidence gethered is untainted it 
    wouldn't be admissible, anyway. The only way I can see for reliable 
    evidence of taint free status is expert witnesses and scientific proof. 
    Both of these are expensive and liable to being reversed occasionally. 
    Business doesn't want either to get used - too hard.
    
    Why - as normal, you find this out when you interview the suspect you've 
    caught, and use induction on the actions taken to adduce state of mind.
    
    Outside the CJS, when logging for administrative purposes, the data is 
    more or less meaningless without some some background info to give it a 
    context ( things like lists of machine names, mac addresses etc. ) which 
    generally only exist within the admin domain and is not really portable 
    without Technical understanding.
    
    When there is an accepted legal definition of what an "account" on a 
    "host" on an "address" is, we'll be able to move forward on something more 
    than a "case by case" basis. Don't hold your breath.
    
    As well as the stuff Marcus has shown on the logging data attribute map I 
    think we should start with the local equivalent of "uname -a" before we 
    log anything else - this flavours the context of most everything 
    collected. ( maybe that's what you mean by SRCDEV? ) Most O/S's don't lie 
    about themselves, yet.
    
    Meanwhile I think it would be good to start to seperate out the "official 
    evidence" aspects from the  "administrative audit" stuff beyond the "bits 
    in common".
    
    And I think Marcus got the "bits in common" right already.
    
    What have I got wrong, here?
    
    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 : Mon Dec 30 2002 - 22:26:02 PST