On Wed, 12 Jun 2002, Ben Nagy wrote:
> level") and a tamper-evident log auditor. [1] For other OS's - we need > to have indelible log generation. Simply sending those messages out as Let's not forget that the OS running the services may not need to be the only OS running (Don't know how much UML and pico kernel stuff you've looked at in this context...) > they occur to a syslog server may be enough for some people, although we > risk someone killing the syslog process as their first action. Some > folks attach line printers to serial ports for this reason. Self > contained logs on most general purpose OS's must obviously be taken with > a pinch of salt, and ditto any system that uses batched or on-demand > transfers. We could, in a virtual or layered multi-kernel environement (and this doesn't directly address the insider stuff, but may be interesting[1] for the attacker-compromise stuff do some transaction journaling on the real/host side that replays logs and potentially machine actions against the virutal/guest infrastructure. > At the collector: The collector needs to be as secure as possible, > obviously. I guess that would mean it should be single purpose. Denial > of Service, which is often only an annoyance against "normal" systems > can be a critical security issue against a log collector, so collectors > need to be as robust as possible in that regard. Unfortunately the I'm not sure- it may be that a DoS against the collector is indicative of an event of a magnitude that obliviates the need for logs, and more importantly you can trade architecture for robustness (out of band logging for instance could happen to a box you wouldn't put on the data network. > new doors for DoS. Third party admin, as Bernd suggests, may be good, > but unless we're up to scratch on the other two fronts we still don't > win against an internal attacker, and if it's only maintaining complete We may win against internal attackers in other ways (video, workstation monitoring, other-group network monitoring...) so let's not limit solutions to a single point of information. > And I _still_ say that this is not one of the nuts that is best turned > by the PKI monkey-wrench. Agreed. Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." -- Firewalls mailing list - [ [EMAIL PROTECTED] ] To unsubscribe: http://www.isc.org/services/public/lists/firewalls.html
