Not so much related to the reliable timestamps, but related to encryption, authentication and reliable delivery: syslog-reliable. Through the use of the BEEP protocol, one can specify authentication profiles or transport encryption profiles or both. Although syslog-reliable may not meet all of the needs discussed here, by getting involved in the process on can affect a change or an extension of the protocol to include those features. At this time, syslog-reliable is an internet draft, and Chris Lonvick is probably in a better position to say where Mr. Rose stands on moving it from internet draft to standards track. But, since syslog-reliable serves as an implementation of BEEP (which is on the standards track), I would be willing to bet that syslog-reliable will move towards the standards track relatively soon... and we want a "standard", correct? Related URLs: syslog-reliable ftp://ftp.isi.edu/internet-drafts/draft-ietf-syslog-reliable-12.txt BEEP (Blocks Extensible Exchange Protocol) http://beepcore.org/beepcore/home.jsp http://www.ietf.org/rfc/rfc3080.txt?number=3080 -- J. Gregory Wright Senior Software Engineer AT&T Information Security Center -----Original Message----- From: Been Reading Your Logs Lately? [mailto:tanat_private] Sent: Thursday, August 16, 2001 2:47 PM To: Mordechai T. Abzug Cc: todd glassey; edward.j.sargissonat_private; michielat_private; loganalysisat_private Subject: Re: [loganalysis] Logging standards and such He *DID* say *reliable*. While NTP provides a time-sync mechanism, the security of NTP has come into question (http://citeseer.nj.nec.com/cache/papers2/cs/873/http:zSzzSzolympus.cs.ucdav is.eduzSz~bishopzSzscrivzSzdart-mcs-91-154.pdf/bishop90security.pdf) and a number of efforts are underway to improve that. Additionally, the use of cryptography to tie a log message to a system and machine is something that could benefit an argument in court (or even just amongst decision makers on the incident response team). While a logging protocol does need to focus on message formats, the mechanisms by which it communicates between systems and the centralized logging server need to be addressed as well. Using the flawed, existing protocols to address those needs will only lead to a less reliable outcome. The home-grown heart-beat mechanism mentioned in a previous message only underscores the fact that the communciations mechanisms for logging protocols are lacking. Since the premise of logging in the incident response context is that the machine generating the messages has been compromised and the logs potentially altered, communications to a centralized server in some reliable manner, is a laudable goal. Thinking along these same lines, we need to consider that a centralized server should not accept messages from un-authenticated clients since it will be dealing with "user supplied" inputs from those clients. While authentication doesn't eliminate user supplied inputs from the equation, it does limit the source to machines which need to be compromised before the centralized logging service can be played with. Sure we can home-grow heart-beat mechanisms and shovel data through make-shift tunnels and use network ACLs to restrict access to the centralized logging service but every logging implementation should address these and a host of other needs common to all IDS/forensics/incident response efforts. Why not address message formats AND communications mechanisms together? That way when I throw up that network ACL, I'm layering my security instead of just relying on that ACL. On Thu, 16 Aug 2001, Mordechai T. Abzug wrote: > On Wed, Aug 15, 2001 at 05:03:54PM -0700, todd glassey wrote: > > As long as we are going to this level of trouble we need a reliable > > timestamp process with a traceable source of time so that logging data can > > be compared to other logging data. > > You mean like the NTP protocol family? There's no reason to come up > with a problem-specific solution when there's already a general > solution. > > - Morty > > --------------------------------------------------------------------- > 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 : Fri Aug 17 2001 - 08:47:48 PDT