Logs do >not< fall under the hearsay exception unless they
contain data manually entered by a human. According to the
Justice Department report I quoted, hearsay is specifically
designed as information provided by a person, not information
automatically generated by a machine -- so different rules
apply.
Read the report!
t.
"I was being patient, but it took too long." -
Anya, "Buffy the Vampire Slayer"
Log Analysis: http://www.counterpane.com/log-analysis.html
VPN: http://kubarb.phsx.ukans.edu/~tbird/vpn.html
On Sun, 16 Dec 2001, Bill Spernow wrote:
> I am a little late to this discussion, so forgive me if I am restating
> previous issues, but given I have had some practical experience in this
> arena, and have trained well over 3,000 cops worldwide on cyber
> investigative techniques, let me add:
>
> (1) Any log data that can be printed out can be successfully introduced as
> evidence in a US court trial (assuming the Attorney is competent).
>
> (2) Any log maintained in the "normal course of business" falls under the
> hearsay exception and can easily be admitted into evidence.
>
> (3) Any log evidence that is created/acquired as a "result" of an
> investigation into the source of a compromise can be challenged, but (as
> mentioned) if there no indications that the original document/log file
> created (or a true and accurate copy) was not tampered with, then it will be
> difficult from keeping it being introduced as evidence.
>
> (4) Most challenges to any forensic computer data pivot on the chain of
> custody and the methodology used to gather/discover it, as opposed to the
> original data itself.
>
> Until then...
>
> Bill Spernow, CISSP
> Chief Information Security Officer
> Georgia Student Finance Commission
> (w) 770-724-9328 (f) 770-724-9004
> cisoat_private (business)
> bill.spernowat_private (personal)
>
>
>
>
> -----Original Message-----
> From: jamie rishaw [mailto:jrishawat_private]
> Sent: Sunday, December 16, 2001 4:13 PM
> To: Tina Bird
> Cc: Log Analysis Mailing List
> Subject: Re: [logs] Data for Court
>
>
> On Sat, Dec 15, 2001 at 04:11:13AM -0600, Tina Bird wrote:
> > Hi all -- I've spent some of my time on airplanes reading
> > the US Dept. of Justice report on Evidence Quality Computer
> > Data (the link is on the Web site). I won't go into great
> > detail (I'm >loving< European central heating), but the thing
> > I found the most interesting is that, despite all the great
> > discussions about how easy it is to modify log data,
> > >unless< there's reasonable proof that logs have been
> > modified, they can be admitted as evidence.
> >
> > Even better, they're generally held to be reliable evidence
> > if the business submitting them collects them as part of
> > normal practice and relies upon their information for its
> > day-to-day activity.
>
> Exactly.
>
> What's important (from what I'm learning from @Stake, an imho great
> security organization) is that the company has what's recognized as a
> baseline of what's "normal".
>
> One @stake staffer wrote to me in an e-mail on this exact topic:
>
> --snip--
> The first goal any conscious
> security professional should achieve is a aperture database. An aperture
> into your technical and corporate environment, that is captured by a matrix
> of what a corporation has and the "cause" (function) vs. "reaction" for
> each of the respective assets. In doing so one has established a baseline
> for what normal is. On a network, a high level example would be ...2
> exchange mail servers : pop mail protocol (110) , internal and external
> uses. For auditing purposes, one can accumulate 12 months of logs filtered
> on the mail server that outline only port 110 was used from the following
> internal IP addresses over the course of the last year. As you have defined
> what is normal, then justified the statement with substantial evidence
> (time stamped logs that were protected and uncorrupted {the security
> measure put in place to protect the logging server was ample}), now when an
> incident happens and one is scrubbing through sanitized data and isolates
> an invalid IP address that accessed the mail server on port 22 at the same
> time that your router's logs, firewalls, etc...noticed anomalies compared
> to your aperture...the information is painted in a different light.
> --snip--
>
> Hope this helps a little.
>
> jamie
>
> --
> jamie rishaw <jamieat_private>
> sr. wan/unix engineer/ninja // playboy enterprises inc.
> [opinions stated are mine, and are not necessarily those of the bunny]
>
> "UNIX was not designed to stop people from doing stupid things, because
> that would also stop them from doing clever things." -- Doug Gwyn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: loganalysis-unsubscribeat_private
> For additional commands, e-mail: loganalysis-helpat_private
>
---------------------------------------------------------------------
To unsubscribe, e-mail: loganalysis-unsubscribeat_private
For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Mon Dec 17 2001 - 11:26:55 PST