Re: [logs] Log Analysis for Law Enforcement

From: Buck Buchanan (lbuchanaat_private)
Date: Mon Jan 20 2003 - 07:59:00 PST

  • Next message: Klaus Moeller: "Re: [logs] How are people bringing DMZ syslog msgs into the central server?"

    Bennett Todd <betat_private> commented in a response to a posting by me:
    >> Hopefully this tool would have the smarts to figure out the
    >> differences between the clocks on the system supplying the logs,
    >> and to be able to determine the clock drift.
    >That'd be nice, but it requires more information than I've seen
    >preserved in syslogs. The easiest fix to this problem is to just
    >eliminate the clock skew and drift, by running good time
    >synchronization code like ntp (which I'm not all that fond of) or
    >clockspeed (which I prefer).
    First a minor correction, I should have said systems.  Second I should give
    attribution to Eoghan Casey for the idea behind the wish for time "smarts".
    For more on this see his article "Error, Uncertainty, and Loss in Digital
    Evidence" in the International Journal of Digital Evidence
    In an ideal world, all systems would have WWV(B),  GPS, and other radio
    broadcast time signal receivers built in along with network synchronization
    for those systems that can not sync to a broadcast signal.  Also in an
    ideal world, there would be sub-microsecond delay between an event and the
    timestamp generation of the event.  Reality is most systems are not
    synchronized, and there can be significant delays in timestamping events.
    Timestamps in logs can be tampered with.
    I envision a time synchronization tool being given logs covering a minimum
    of several hours of logs from multiple systems that are supposed to cover
    the time period of interest.  The tool would scan the logs to look for
    events that would be common to two or more systems.  For any pair of
    systems, the tool would identify events that originate on each system and
    result in a log entry on the other.  By analyzing these events the tool
    should be able to estimate the time difference and network delays with
    error bounds on those estimates.  Analyzing events several hours later to
    compute another time difference estimate would give some idea of the clock
    drift between the systems.  Development of this tool would also require
    determining the characteristics of timestamping delays for various common
    operating systems to further aid in computing the uncertainty bounds on an
    event.  The logs given to the tool to analyze should be given
    trustworthiness ratings relative to the other logs.  There is lots more on
    the wish list, but this will provide a basis for a start.
    B Cing U
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Mon Jan 20 2003 - 09:59:05 PST