|
Monitoring Event Logs
A successful strategy for monitoring event logs must take several factors into
consideration, specifically what items to monitor, how often to monitor the logs,
total bandwidth available for monitoring, reducing false positives among
detected events, and how to notify appropriate parties when an alarm is triggered.
What items must I monitor?
Every organization has different rules on what sorts of events they must monitor. Typically,
IT departments often focus on security events almost to the exclusion of everything else. While
security is of paramount importance to any network administrator, it is important not to ignore
vital information about network health placed in other event logs. For example, the System
event log often records information about FTP server activity such as bad logons, and the
Application event log is typically the best place to look for virus detections by third-party
anti-virus solutions.
Furthermore, the amount of data you monitor affects the total amount of bandwidth used by your
monitoring solution, and adds to the overhead of that system. In general, less is better -
meaning, the fewer events you must monitor in real time, the lower the hardware
and available bandwidth requirements must be to meet your objectives.
How often should I monitor my logs?
Most administrators like to perform either continuous or episodic
monitoring.
Continous monitoring involves the continual checking of event logs
for critical incoming events in real time. To accomplish this, administrators typically
rely on an automated piece of software to poll each event log of interest at a recurring
interval and notify them when a log entry of interest is detected.
Episodic monitoring involves the close scrutiny of one or more event logs as
dictated by a recent event - e.g. a server crash, a virus outbreak, etc. While episodic
monitoring does not require automated software (a clever administrator can manually
sift through her logs daily), it is often enhanced by such software. In some cases,
administrators will simply focus their software on specific logs when needed.
In all cases, make sure that the system you use for the automated monitoring of event
logs offers the administrator the ability to adjust its log polling interval. As
bandwidth consumption is a function of data moved over time, reducing the frequency of
polling can reduce bandwidth needs.
How can I minimize bandwidth costs?
Every network is different, and so it's very important to take into account your network
topology when rolling out an event log monitoring solution. The impact of continuous
monitoring on a 100-MBit switched network, for instance, will be much less than the same
level of monitoring on an unswitched 10-Mbit network. Fortunately, there are several
ways to reduce bandwidth demands placed on your network by a monitoring solution:
- Only audit (e.g. log) the events you are most concerned about. For example,
turning on object access auditing for all files and all groups will flood the security
log with events and add greatly to auditing overhead.
- Install monitoring software at different network locations to take advantage of
high bandwidth areas. For example, many companies use a switched, gigabit backplane
to connect their mission-critical servers. Consider installing monitoring software on
one of the servers in the backplane, and let it monitor the other machines in the
backplane.
- Install monitoring software locally on servers that perform a high volume of
auditing. This will minimize bandwidth, as traffic may only travel on the wire when
an event is actually detected.
How can I reduce false positives?
The effectiveness of any log monitoring solution is marginalized by false positives,
or in other words, the detection of events with little significance to the administrator.
Whenever possible, define thresholds for certain types of events to reduce the detection
of trival issues. For example, consider adding thresholds to logon failures, so that
notification only takes place after a certain number of logon failures occur within
a specific time frame (e.g. 10 minutes). Adding a threshold here will prevent benign
notifications related to users forgetting their passwords when logging on, but will
still catch most brute-force hacking attempts.
What are the best methods of notification?
In the past, pager notifications were one of the best ways to alert IT staff of an impending
problem. However, most pagers have a limit on the amount of information they can receive
in a single notification. Since most wireless communication devices (e.g. cell phones) can
receive e-mail, sending notifications via e-mail will most likely be the preferred method on
most modern networks. In addition, the administrator should consider adding database
storage as part of their notification strategy, so that they have a history of events that
triggered notifications for additional analysis purposes.
Other resources:
Event Alarm
Software capable of realtime monitoring of event logs
and syslogs.
|