Enable Auditing on Servers & Workstations

If no Audit policy exists, it will be difficult or impossible to determine what took place during a security incident. However, if audit settings are configured so that many authorized activities generate events, the Security log will fill up with useless data. The following recommendations and setting descriptions are provided to help you determine what to monitor so that the collected data is relevant.

While this is a fairly normal practice for servers, it isn't usually performed on workstations unless there is a high risk of data theft. Our philosophy is that the time to fix the roof is before it starts to rain. By selectively auditing a few key actions, you'll have a place to start investigating theft or destruction of data if someone ever does compromise your workstation. We recommend auditing the following actions:

GPEDIT.MSC >

Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy

	Setting Legacy Client Windows NT	Enterprise Client Windows 2000 pro. Windows XP, Vista	Servers Specialized Security &endash; Limited Functionality
Event	Level of Auditing	Level of Auditing	Level of Auditing
Audit account logon events	Success	Success, Failure	Success, Failure
Audit account management	Success	Success, Failure	Success, Failure
Audit Directory Service access	Success	Success, Failure	Success, Failure
Audit logon events	Success	Success, Failure	Success, Failure
*Audit Object access (for File Access monitoring)	No auditing	No auditing	No auditing Subject to server usage
Audit Policy change	Success	Success, Failure	Success, Failure
Audit Privilege use	Success	Success, Failure	Success, Failure
**Audit Process Tracking	No auditing	No auditing	No auditing
Audit System events	Success	Success, Failure	Success, Failure

*Audit Object access

By itself, this policy setting will not cause any events to be audited. The Audit object access setting determines whether to audit the event when a user accesses an object&emdash;for example, a file, folder, registry key, or printer&emdash;that has a specified system access control list (SACL).

**Audit process tracking

This policy setting determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access. If you configure this policy setting to log Success values, an audit entry is generated each time that the process that is being tracked succeeds. If you configure this policy setting to log Failure values, an audit entry is generated each time that the process that is being tracked fails.

The Audit process tracking setting will generate a large number of events, so it is typically configured to No auditing, as it is in the baseline policy for all three environments that are defined in this guide. However, this policy setting can be very helpful during an incident response because it provides a detailed log of the processes that are started and the time when each one was launched.