Re: Log integrity handling on central logsystem

All,

I would second what Eric said; my research also pointed me in a
similar direction - the burden of proof will likely be on the
"attacking" side which would need to proof that that the logs *were*
tampered with rather than the other way.

This DoJ paper is actually a bit more clear than their rules of
evidence: http://www.usdoj.gov/criminal/cybercrime/usamarch2001_4.htm

On 8/31/06, Eric Fitzgerald <[email protected]> wrote:
>
>
>
> Hi Christina,
>
>
>
> The federal rules of evidence actually point in the other direction, that
> U.S. Federal courts look at the likelihood of tampering having actually
> occurred rather than the possibility of tampering.
>
> http://www.cybercrime.gov/usamarch2001_4.htm
>
>
>
> Here's an excerpt from an article by Orin S. Kerr (a DoJ attorney when the
> article was written) on Computer Records and the Federal Rules of Evidence:
>
>
>
> "Computer records can be altered easily, and opposing parties often allege
> that computer records lack authenticity because they have been tampered with
> or changed after they were created. For example, in United States v.
> Whitaker, 127 F.3d 595, 602 (7th Cir. 1997), the government retrieved
> computer files from the computer of a narcotics dealer named Frost. The
> files from Frost's computer included detailed records of narcotics sales by
> three aliases: "Me" (Frost himself, presumably), "Gator" (the nickname of
> Frost's co-defendant Whitaker), and "Cruz" (the nickname of another dealer).
> After the government permitted Frost to help retrieve the evidence from his
> computer and declined to establish a formal chain of custody for the
> computer at trial, Whitaker argued that the files implicating him through
> his alias were not properly authenticated. Whitaker argued that "with a few
> rapid keystrokes, Frost could have easily added Whitaker's alias, 'Gator' to
> the printouts in order to finger Whitaker and to appear more helpful to the
> government." Id. at 602."
>
> "The courts have responded with considerable skepticism to such unsupported
> claims that computer records have been altered. Absent specific evidence
> that tampering occurred, the mere possibility of tampering does not affect
> the authenticity of a computer record. See Whitaker, 127 F.3d at 602
> (declining to disturb trial judge's ruling that computer records were
> admissible because allegation of tampering was "almost wild-eyed speculation
> . . . [without] evidence to support such a scenario"); United States v.
> Bonallo, 858 F.2d 1427, 1436 (9th Cir. 1988) ("The fact that it is possible
> to alter data contained in a computer is plainly insufficient to establish
> untrustworthiness."); United States v. Glasser, 773 F.2d 1553, 1559 (11th
> Cir. 1985) ("The existence of an air-tight security system [to prevent
> tampering] is not, however, a prerequisite to the admissibility of computer
> printouts. If such a prerequisite did exist, it would become virtually
> impossible to admit computer-generated records; the party opposing admission
> would have to show only that a better security system was feasible."). Id.
> at 559. This is consistent with the rule used to establish the authenticity
> of other evidence such as narcotics. See United States v. Allen, 106 F.3d
> 695, 700 (6th Cir. 1997) ("Merely raising the possibility of tampering is
> insufficient to render evidence inadmissible."). Absent specific evidence of
> tampering, allegations that computer records have been altered go to their
> weight, not their admissibility. See Bonallo, 858 F.2d at 1436."
>
>
>
> I agree that signing (strong evidence collection & chain of custody
> procedures) will help dismiss such accusations more briefly, but I don't
> believe that signing is necessary for introduction of logs as evidence.
>
>
>
> Cash register receipts, another kind of electronic evidence, won't have
> digsig for probably decades yet are readily admissible providing that
> receipts are part of normal business process.
>
>
>
> Now your last statement regarding best practices is the real heart of the
> matter, and I think that's really the most important concern.
>
>
>
> Thank you very much for your detailed thoughts!
>
>
>
> Best regards,
>
> Eric
>
>
>
>
>
>
>
>
> ________________________________
>
>
> From: Christina Noren [mailto:[email protected]]
> Sent: Thursday, August 31, 2006 11:50 AM
> To: Eric Fitzgerald
> Cc: [email protected]
> Subject: Re: [logs] Re: Log integrity handling on central logsystem
>
>
>
>
> Eric,
>
>
>
>
>
> There are many regs out their that speak generally about taking steps to
> prove the integrity of logs. (HIPAA, DCID, NISPOM, FFIEC... the list goes
> on). Some mention log signing as a technique. Many more focus on security of
> network transmission (i.e. syslog-ng or similar) and controls over access to
> the log data repository.
>
>
>
>
>
> However, real driver for signing is litigation risk, not regulations.
>
>
>
>
>
> When you present log data as evidence to prosecute intruders, or you are
> subpoenaed for log evidence, opposing counsel will tend to challenge its
> integrity on several points:
>
>
>
>
>
> - can't prove that there weren't additional exculpatory records showing
> someone other than the defendant had the same opportunity, if the evidence
> is circumstantial, that were then deleted by the _real_ culprit
>
>
> - can't prove the specific events used as evidence weren't changed
>
>
>
>
>
> Signing (with a nonce that can be proven to have been protected) both
> individual log events and groups of consecutive log events is one of the
> best ways to address this type of challenge.
>
>
>
>
>
> Furthermore, to the extent that log signing becomes standard practice, a
> company who does not do it is exposed to civil litigation for not having
> taken due care, if outsiders, employees, customers, etc. are unable to
> pursue lawsuits against 3rd parties because of   the shakiness of the log
> evidence.
>
>
>
>
>
> - Christina
>
>
>
>
>
> On Aug 31, 2006, at 1:00 AM, Eric Fitzgerald wrote:
>
>
>
>
>
>
> Regarding log signing: is anyone aware of an actual regulatory or legal
> requirement for log signing?
>
>
>
>
>
>
> ________________________________
>
>
> From:
> [email protected]
> on behalf of Christopher L. Petersen
> Sent: Tue 8/22/2006 6:55 AM
> To: Patrick Debois; [email protected]
> Subject: [logs] Re: Log integrity handling on central logsystem
>
>
> I've always thought ensuring the integrity of the log begins at
> collection and ends at archival.  In defining integrity I would say it
> means no log entries are altered and the complete log is collected and
> centralized.  As for best practices, I would recommend the following:
>
> - Collect all logs as close to real-time as possible.  The longer the
> source log is on the source host, the more likely it can be altered.
> - When possible transport logs with a TCP based protocol and encrypt.
> TCP ensures reliability and combined with encryption, makes altering log
> entries as they traverse the network significantly more challenging.
> - If UDP Syslog is the only option and the central repository is across
> the WAN, try to collect close to the source and then forward via a TCP
> based protocol.
> - The central repository should utilize a strong access control
> mechanism at the operating system, database, and application layer to
> ensure that log data cannot be altered once written.
> - Ideally, an archive/backup copy of all centralized logs should be
> maintained.  This provides redundancy in the event the central log
> database fails or becomes corrupt.
> - When written to the central repository/archive, additional controls
> like hashsums or digital signatures can be used to validate integrity.
> If hashsums and/or signatures are used make sure the proper access
> controls exist around storing the hashes and signatures to ensure they
> cannot be modified.  This in itself is another line of thought...
> - If you want to get really serious (and spend some money), write
> archive copies of the logs to write-once storage.
>
> I'm not sure if/how Splunk addresses the above.  Vendors focused on log
> management (vs SIM) address most if not all of the above.
>
> Chris Petersen,
> CTO & Founder
> LogRhythm, Inc.
> www.LogRhythm.com
>
> > -----Original Message-----
> > From:
> [email protected]
> >
> [mailto:[email protected]
> ]
> > On Behalf Of Patrick Debois
> > Sent: Tuesday, August 22, 2006 12:44 AM
> > To: [email protected]
> > Subject: [logs] Log integrity handling on central logsystem
> >
> > I'm looking for feedback how centralized log solutions handle data
> > integrity; If you would log directly to a central system, that log is
> > the only source. So you would miss something to compare against.
> >
> > -Would you rely on taking checksums of the logs and storing them on
> > another system?
> > -How do you protect yourself from the fact that the central logging is
> > compromised with a still growing logfile?
> > Would you consider signing each log line? Signing within a text file
> is
> > fairly easy, but what about content stored in a database?
> >
> > My customer is currently looking at Splunk. It seems a great way to go
> > through the logfiles, but I'm not sure that we can fullfill his
> > dataintegrity requirements with it. But then again it does not stand
> in
> > the way of another solution doing it probable.
> >
> > Patrick
> >
> >
> > _______________________________________________
> > LogAnalysis mailing list
> > [email protected]
> > http://lists.shmoo.com/mailman/listinfo/loganalysis
> _______________________________________________
> LogAnalysis mailing list
> [email protected]
> http://lists.shmoo.com/mailman/listinfo/loganalysis
>
>
> _______________________________________________
>
>
> LogAnalysis mailing list
>
>
> [email protected]
>
>
> http://lists.shmoo.com/mailman/listinfo/loganalysis
>
>
>
> _______________________________________________
> LogAnalysis mailing list
> [email protected]
> http://lists.shmoo.com/mailman/listinfo/loganalysis
>
>
>


-- 
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
     http://www.chuvakin.org
 http://chuvakin.blogspot.com
http://www.securitywarrior.com