Re: [logs] "Temperproof" logfiles?

From: todd glassey (todd.glasseyat_private)
Date: Tue May 13 2003 - 08:06:20 PDT

  • Next message: Tina Bird: "Re: [logs] "Temperproof" logfiles?"

    So why are checksums not needed?  the issue is what constitutes a reliable
    audit model and this group doesn't have all that many auditors as far as I
    can tell so this is a technologist telling you what is necessary and once
    again we are at that impasse where technology say's "this is what you get"
    and commerce saying "we need XY&Z not that"
    
    One of the things that we as systems admins need to come to grips with is
    that it is us that these non-repudiate logging systems are really meant to
    protect the systems from and most of us are really offended at that, but in
    reality its the way it is. Take heart the oracle DBA's are in the same boat.
    No self-respecting Commerce Auditor believes a word the DBA's say without
    hard evidence. Just the way it is.
    
    Todd
    
    ----- Original Message ----- 
    From: "Rainer Gerhards" <rgerhardsat_private>
    To: "Jason Haar" <Jason.Haarat_private>
    Cc: <loganalysisat_private>
    Sent: Friday, April 04, 2003 12:33 AM
    Subject: RE: [logs] "Temperproof" logfiles?
    
    
    > I agree that checksums are not necessarily needed (and not necessarily
    > helpful). Just have a look at the list archives, and you'll see some
    > great discussions on this topic which provide great insight.
    >
    > However, I believe that checksums will probably *add* to the credibility
    > of the data ... just one step further. But nothing more and - in my
    > point of view - definitely not vital.
    >
    > Rainer
    >
    > > -----Original Message-----
    > > From: Jason Haar [mailto:Jason.Haarat_private]
    > > Sent: Friday, April 04, 2003 6:49 AM
    > > To: Log Analysis List
    > > Subject: Re: [logs] "Temperproof" logfiles?
    > >
    > >
    > > On Thu, Apr 03, 2003 at 04:04:43PM -0500, Blaise St-Laurent wrote:
    > > > the more i think about it though, the less i think that database +
    > > > tamper resistance is going to be an syslog issue. If you
    > > want to sign
    > > > or at least put a checksum against every line that goes
    > > into your db,
    > > > the best way i could think of doing this is to write a trigger on
    > > > insert that calculates the checksum based on the values you supply
    > > > (time, server, msg etc..) and adds it to the appropriate
    > > column. I'm
    > >
    > > I may be showing my ignorance here, but can someone explain
    > > to me how checksums *by themselves* actually "prove" the data
    > > hasn't been tampered with?
    > >
    > > I mean, if I have a years worth of syslog data, md5 checksum
    > > the files, and burn them all off onto tape. A year later in
    > > court, I can confidently say that the syslog data *as it is
    > > on the tape* is as valid today as it was *when the tape was
    > > written* (as the checksum will hopefully match).
    > >
    > > I mean, as far as legal goes, surely all that this
    > > checksumming does it "prove" the data hasn't been altered
    > > *since it was written*. It doesn't say anything about me
    > > fiddling with it before I checksumed it...
    > >
    > > Surely in court, it's simply about proving your copy of the
    > > data hasn't been altered since it was written, and then it's
    > > *totally* a "reliability of the witness" type problem after that...?
    > >
    > > Similarly, if you have some nice proprietary "logging server"
    > > that can take input from syslog clients and it puts it into a
    > > checksummed database you can't fiddle with as you don't know
    > > how it works, then you can still input bogus data can't you...
    > >
    > > I don't understand why this issue is always shown off as
    > > being a technical issue, when it court is usually ends up
    > > being a "people issue" (i.e. do they trust you)?
    > >
    > > -- 
    > > Cheers
    > >
    > > Jason Haar
    > > Information Security Manager, Trimble Navigation Ltd.
    > > Phone: +64 3 9635 377 Fax: +64 3 9635 417
    > > PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D
    > > 66D1 _______________________________________________
    > > LogAnalysis mailing list
    > > LogAnalysisat_private
    > > http://lists.shmoo.com/mailman/listinfo/logana> lysis
    > >
    >
    > _______________________________________________
    > LogAnalysis mailing list
    > LogAnalysisat_private
    > http://lists.shmoo.com/mailman/listinfo/loganalysis
    
    _______________________________________________
    LogAnalysis mailing list
    LogAnalysisat_private
    http://lists.shmoo.com/mailman/listinfo/loganalysis
    



    This archive was generated by hypermail 2b30 : Tue May 13 2003 - 10:31:48 PDT