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.ucdavis.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
This archive was generated by hypermail 2b30 : Thu Aug 16 2001 - 12:28:14 PDT