Determining Which Events to Audit

The first step in creating a strategy for auditing the OS is to determine the type of actions or operations to record. Which OS events should you audit? The easy answer to this question is all of them. Unfortunately, auditing all OS events would require enormous system resources and could negatively affect system performance. Bear in mind that the more you audit, the more events you generate and the more difficult it can be to spot critical events. If you plan to monitor the audited events manually or if you do not have a clear understanding of how to read audit logs, it can be extremely difficult to isolate potential malicious events from innocuous ones. You will need to work with other security specialists ideally those who specialize in forensics or computer crime investigations and IT decision makers to determine the OS events to audit. Audit only those events that you believe will be useful for later reference. Although this is certainly easier said than done, many of these events will be readily apparent. For example, you should audit account management and account logon events.

If your organization does not have a security policy for auditing, an effective way to begin determining which events to audit is to gather all the relevant people in your organization in a room and brainstorm. Determine the following:

The actions or operations you want to track
The systems on which you want these events tracked

For example:

We want to track all domain and local logon events to all computers.
We want to track the use of all files in the payroll folder on the HR server.

You can later match these audit statements to the audit policies and settings in the OS.

In Microsoft Windows NT, Microsoft Windows 2000, and Microsoft Windows XP, audit events can be split into two categories: success events and failure events. A success event indicates that the action or operation has been successfully completed by the OS, whereas a failure event shows that the action or operation was attempted but did not succeed. Failure events are useful in tracking attempted attacks on your environment; success events are much more difficult to interpret. Although the vast majority of successful audit events are simply indications of normal activity, an attacker who manages to gain access to a system will also generate a success event. Often, a pattern of events is as important as the events themselves. For example, a series of failures followed by a success might indicate an attempted attack that was eventually successful. Similarly, the deviation from a pattern might also indicate suspicious activity. For example, suppose the audit logs show that a user at your company logs on every workday between 8 A.M. and 10 P.M., but suddenly you see that this user is logging on to the network at 3 A.M. Although this behavior might be innocuous, it should be investigated.