Re: decoy traffic and legal admissibility of logs in court

["Ron Hale" <rhale () tri-sage com>]

While I am not an attorney I have had some experience in investigations and
evidence presentation in court.  The problem with logs is that they cannot
speak for themselves.  They need to be interpreted by a court approved
expert.  Approval as an expert is left to the judge after both sides have an
opportunity to question the experts qualifications.

Outside of how testimony about logs is provided there is a big issue as to the
admissibility of logs as evidence in the first place.  I always felt that the
best defense was to bring into question the general security practices of a
site.  Poor password practices, insecure design and implementation, lack of
real time monitoring, the inability to detect and respond to serious
conditions and so on question the utility of any computer records that can be
used to demonstrate who did something and how.  If you can't prove that one
person did something and have the weight of that proof to go to the level of
reasonableness then the computer record is of little value.  Logs as far as I
have seen are of questionable value since it is difficult to demonstrate that
they have not been modified, that the records themselves contain accurate
information, or that the really speak to a true incident.  At best logs can
only be used to support a great deal of other information that points to a
particular suspect.

Ken Williams wrote:

> during conversation recently about some network hacks in which a number
> of machines were compromised, and while i was going through logs of
> several machines that have been compromised on a couple of different
> networks that i admin, an interesting legal issue regarding decoy traffic
> came up.  after analysis of logs, it has become clear that some of the
> traffic can definitely be attributed to decoys/spoofing.  consequently,
> the question of the validity of system logs and the legal admissibility of
> logs in court, in general, has arisen.  the recent issue regarding
> Linux kernels <= 2.0.35 and blind tcp spoofing figures into the equation
> too now, especially with the release of the receive.c and lin35.c spoof
> code.
>
> thoughts? comments? suggestions? flames?
>
> take it easy,
>
> Ken Williams
> jkwilli2 () csc ncsu edu
>
> Packet Storm Security                 http://packetstorm.genocide2600.com/
> Trinux: Linux Security Toolkit http://www.trinux.org/ ftp://ftp.trinux.org
> PGP DH/DSS/RSA Public Keys     http://packetstorm.genocide2600.com/pgpkey/
> NCSU Computer Science    http://www.csc.ncsu.edu/    jkwilli2 () csc ncsu edu
> SHANG: Secure Highly Available Networking Group http://shang.csc.ncsu.edu/



--
Ron Hale, rhale () Tri-Sage com
Tri-Sage, Inc.     Phone: 630-241-0500     Fax: 630-241-3835
The Premier Security Integrator -- Visit us at www.Tri-Sage.com