While I would agree that syslog alone can be easily made inadmissable in court, one can also set up the appropriate security defenses to negate most of those arguments. Such as local filter software on the syslog host such as ipchains or others. Also filtering at the router level. These serve to "firewall" off the machine and one could control where the syslog data was originating from. This would not, however, stop someone from compromising a machine that is allowed and send syslogs the falsify syslog messages from that host, thus bypassing this type of security. Log to mutiple hosts so you could see time differences to show log time patterns, etc?? The real question (and one that will have no basis in logic!) is where will the courts find log data to be as reliable a source as say a "word of mouth" evidence stream? i.e. Joe User's word against Sarah Managers word. An Example: Currently they will take Sarah Managers dated notebook as evidence even though she could have made most of that up at any time as there is no witness to her pers. notes! A judge or most lawyers will have little or no visability/understanding into our world and will translate our evidence into "paper" evidence and treat it as such?? The plot thickens! John P. Harris Jr. SANS GSEC Engineering Solutions & Tech Competencies EDS Northeast Region I.Solutions Phone: (716) 231-0986 Fax: (716) 231-0232 E-Mail: John.Harrisat_private Buick Club of America # 37854 On Tue, 2001-12-04 at 02:34, Tina Bird wrote: > Pardon me for re-opening this can of worms. > > Did we ever come to a consensus, or a pseudo-consensus, > on due diligence for computer logs as evidentiary > quality data? > > What makes a judge unlikely to admit my logs as evidence? > - unauthenticated data sources ("anyone can write to this > datastream, therefore none of it is reliable") > - lack of time synchronization > - long term storage that is not tamper-proof > - no strategy for dealing with all the data once it's collected > > I would propose -- for your non-existent > Joe Average corporate network (I expect there to be > heated discussion - please tell me where I'm totally > off base) (and of course bearing in mind that this > isn't infallible, it's just as good as the "court" can > expect a "diligent" network or system administrator to > do): > > 1) can't enforce secure transmission protocols throughout > the network, because standards aren't sufficiently > evolved -- so standard syslog, SNMP, SMTP are okay for > transport protocols. (although see #3 below) > 2) central loghost with NTP or other time synchronization > throughout the network -- use ongoing record of process > IDs on logging machines to verify reasonable expectation > that a particular log message came from a given machine > (does that make sense? I know what I mean...) > 3) access control enforced at loghost that limits which > machines can log -- help reduce likelihood of spoofed > traffic -- or implement other transports altogether, like > the serial cable mechanism we've discussed > 4) loghost is of course totally locked down, SSH only > access, or console only access, and dumps logs to > write-once archive format on regular basis > 5) log review and reduction strategy -- anyone want to > take a stab? since presumably part of showing that the > data is reliable is showing that I've thought about how > I should process it. > 6) minimum list of machines on that non-existent typical > network that I should be required to monitor to be > credible? > > Things have been awfully quiet out here lately... > > cheers -- tbird > > "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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Tue Dec 04 2001 - 12:24:55 PST