I suggest you are well on your way to understanding the issues at hand by identifying these different audiences. * System administrators typically use the logs for several purposes - resolving incidents by matching errors to problems so that the known problem can be resolved through a change request (OMIGOD that's so ITIL) - identifying errors to resolve problems before they cause incidents - usually fixates on what is "abnormal" http://www.ranum.com/security/computer_security/editorials/dumb#Enumerat ing_Badness * The IT Manager wants to know - that the above activity is performed (it is generally accepted that this is required as a "best practice") - how much time (money) is spent doing this - how much money (time) was saved by the time (money) spent doing this - that the gap between what security analysts and sys admins do is not overlapped - that he can produce pretty graphs and tables from the events (ok I'm kidding folks) The Auditor typically wants to know - that the above two processes are in place, - the stuff I'm about to talk about is also in place. - to know that it is regularly occurring. - that the procedure meets the standards to which the auditor is holding the targeted organization (often very fuzzy). - that the gap between what security analysts and sys admins do is not too large - that if there are security events that are measurable, that they can be counted and someone is watching for "abnormal" counts based on "normal baselines" whatever that is. The security analyst is attempting to - identify security events that are indicative of security incidents. (I'll define security incidents as exceptional security events that indicate an activity that negatively affects confidentiality, integrity or availablity of IT system or data. - identify enough parameters (what activity happened on what system and how bad) so that they can be contained quickly, eradicated, and recovered from. - identify malicious activity (unintentional security incidents can also fit the bill but should be handled by sys admins as above) - establish baselines for what is "normal", but usually fixates on what is "abnormal" http://www.ranum.com/security/computer_security/editorials/dumb#Enumerat ing_Badness - this is the needle in the haystack, as system logs tend to give lots of indications and warnings that have a wildy variable reliability - the signal to noise ratio tends to be pretty low. This is off the top of my head, from what I've been able to see over the past few years. Hope that helps. The interesting thing is that system logs can also be used to feed a record of all kinds of other security event data from many different security point solutions (firewalls, authentication systems, authorization systems, VPN, antivirus, etc...) and it becomes a big junk-drawer (you have one of those don't you?) of messages that someone has to wade through every once in awhile. People are trying to figure out how to sort out that junk drawer, but this one seems to fill up every day! Wynn -----Original Message----- From: loganalysis-bounces+wynn.fenwick=cgi.com@private [mailto:loganalysis-bounces+wynn.fenwick=cgi.com@private] On Behalf Of pramodhc Sent: Friday, November 03, 2006 4:37 AM To: loganalysis@private Subject: [logs] Log information I am doing a research in event Log Management. I would like to know the following a) What system administrator wants from the event log? b) What IT manager wants to see from event log? c) What auditor wants from event log? d) What does security analyst wants from event log? -Pramodh C _______________________________________________ LogAnalysis mailing list LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis _______________________________________________ LogAnalysis mailing list LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2.1.3 : Fri Nov 03 2006 - 11:51:13 PST