I've long thought about what kinds of things can be derived from a normal, default Event Log, mostly based on my needs at the time. What I was looking for usually depended upon what my job function happened to be at the time. In some cases I might be looking for a particular user's logon time, and in others, I was looking for reports from A/V software.
Now, I'm looking at Event Logs from the perspective of...I don't really know what I'm looking for, or what might be useful. For example, I can cull through a System Event Log and look for instances of event ID 6005 followed by an instance of event ID 6009, which indicate when the system was started. Depending upon the audit configuration of the system, other information can be derived as well.
So...what kinds of things are other looking at, or looking for, in the Event Logs? What types of things should be correlated?
1 comment:
It really depends on what the mission of the day is.
On one job, I wrote a batch script to live on primary domain controllers (or the equivalent PDC emulator in an AD) and hunt for password lockout events. This served a dual purpose: anyone watching the logs (I had it going to a web page that auto-refreshed) would see an attack happen pretty quickly, and respond. Since the computername was logged as well, we could send someone out to investigate usually within minutes of the attempt.
Additionally it helped people who had legitimately locked themselves out to track down where the problem was (most innocent lockouts are the result of two computers logged in during a password change). So that little log parser got lots of bang for the buck.
Other times, a confidential file has gotten loose and (if object access auditing was turned on) we can track everyone who has accessed it within x number of days.
A third example I can think of ... all the database servers were running seti@home but the dba strenuously disavowed having installed these potential backdoors. A quick sort through 'process tracking' entries proved him to be lying.
As for correllation. This is a big one, really. Process tracking makes it easy enough to see processes start but not when they end. Y'know that 'ip conversation' function that Ethereal has? Where you pick a packet and it sorts out all other packets either to or from the same host that are part of that conversation? I envision the Event Log having similar functionality, and I drool. TO be able to just go to a machine and say 'show me all security log entries for user jdoe' ... then selective filter /out/ more and more noise, would be just awesome.
(Event Viewer currently only has an 'include' filter mechanism; no way to define excludes).
I think at least 60% of event log usage is going to be reactive not proactive ... a particular thing has already happened and we turn to the logs to peice out the what-why-when-who-where of it. But with a bit more thinking I bet I could come up with more proactive uses which would trigger alerts *as* something is happening.
Post a Comment