----- Original Message ----- From: "Kohlenberg, Toby" <toby.kohlenbergat_private> To: <loganalysisat_private> Sent: Wednesday, December 05, 2001 12:09 AM Subject: RE: [logs] Due Diligence for Admission in Court > Simple question- regarding the issue below of validity/reliability > of logs and log sources, could this not be addressed by implementing > cryptographic signing of logs by the local logging facilities both on > the servers creating the logs (e.g. application servers) and the > central logging servers? As Emeril says, lets kick this up a notch - The key concept in maintaining the logs is how to remove the local human tamper potential. > It seems like that would provide additional > authentication of the source of logs as well as allowing better integrity > control of the logs.... Yes - there are any number of methods of securing the log content from outside fiddling, but the real feat of magic here is how to eliminate the potential of the systems admin from screwing around with the logs or the DBA for that matter > Or am I completely missing something? > > I do like the idea of sending to multiple central log hosts as a means of > providing validation but how does that stand up against an attacker who > has compromised the system sending the logs and can now manipulate it > directly? The question is one of how tightly coupled these systems are. > I see this as where the signing by the sending server may work- if you use > a signing model where the log facility can only access its private key so > long as its integrity (or maybe the kernel's?) is sound (I am pretty sure > this is possible using some programming techniques that would make most > developers neurotic). If an attack is successful, the private key would no > longer accessible or would be modified such that the signature is different. > Hrm... I need to go find references on this before I go any further with it. > > toby > > All opinions are my own and in no way reflect the views of my employer > --- SNIP --- --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Wed Dec 05 2001 - 13:23:33 PST