Re: [logs] Data for Court

From: Tina Bird (tbird@precision-guesswork.com)
Date: Mon Dec 17 2001 - 09:40:19 PST

  • Next message: jamie rishaw: "Re: [logs] Thoughts needed"

    Hi all --
    
    I am in my warm toasty California office now, with the 
    DoJ report sitting in front of me.  It's
    
    http://www.usdoj.gov/criminal/cybercrime/usamarch2001_4.htm
    
    I agree with Todd's main point -- that sooner or later, courts
    are going to understand that computer records, like >all other
    sorts of evidence<, are subject to tampering.  However, the
    point of the report is:
    
    1) The entity claiming that evidence tampering has occurred 
    has to offer reasonable proof.  OJ Simpson leaps immediately
    to mind.
    2) Logs containing no data manually written by humans does
    not qualify as "hearsay" of any variety, and can be entered
    as evidence if the organization collecting it uses it for
    its own day-to-day record keeping and processing.
    
    Furthermore, although the law is changing, the case law
    cited in the paper covers over 15 years -- which suggests
    to me that we've got time to get things in place now and
    >then< worry about the deeper technical issues.
    
    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 Mon, 17 Dec 2001, todd glassey wrote:
    
    > 
    > ----- Original Message -----
    > From: "jamie rishaw" <jrishawat_private>
    > To: "Tina Bird" <tbird@precision-guesswork.com>
    > Cc: "Log Analysis Mailing List" <loganalysisat_private>
    > Sent: Sunday, December 16, 2001 1:12 PM
    > 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.
    > 
    > This will change - and like as not quickly too. The burden of proof has
    > always been on the accused's side, but not so much in business (See
    > Napoleonic law for instance). What will happen is that as the courts evolve
    > and understand the volatility of computer generated data, they will flip
    > this requirement and for data to be automaticallt admitted or stipulated as
    > to its authenticity by both parties in a matter, the veracity of the system
    > around the logs will need to be proven.
    > 
    > I assure you that on appeal those logs are out of consideration unless there
    > is a very sloppy lawyer running the appeal. With all the written expert
    > testimony already in the marketplace about the ease of tampering with logs
    > if they get included blindly its the lawyers fault and not the issue of the
    > logs themselves.
    > 
    > Todd
    > > >
    > > > 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.
    > 
    > Until someone formally audits the site to refute that the records are real.
    > Especially if they are captured and managed in a distributed manner since
    > there is no authentication or anything else to go along with it. That makes
    > the logs hear-say evidence at best.
    > 
    > >
    > > 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
    > 
    
    
    ---------------------------------------------------------------------
    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 - 12:58:52 PST