Auditing Security Events Best practices
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Best practices
Create an audit plan before implementing audit policy.
Decide what type of information you want to gain by collecting audit events:
If you are interested in intrusion detection--tracking the attempts of users to gain access to areas for which they are not authorized--you can collect failure audits. But enabling failure audits can be a risk to your organization. If users attempt to access a resource for which they are not authorized, they can create so many failure audits that the security log becomes full, and the computer cannot collect any more audits. If you have the Audit: Shut down system immediately if unable to log security audits policy setting enabled, users can start a denial-of-service attack through your audit policy.
If you are interested in forensics--using the audit log to determine exactly what happens in your organization--you can collect a combination of success and failure audits.
Consider the resources that you have available for collecting and reviewing an audit log. Audit events take up space on your computers, and they take up your time and the time of people in your organization. Do not audit events that do not really interest you.
Collect and archive security logs across your organization.
If an intrusion occurs, isolate and preserve the security log entries. These entries can be valuable during an investigation of the intrusion.
An audit trail can contain information about changes that are made to your computer or to other computers on the network. If intruders gain administrator rights and permissions, or if administrators abuse their rights and permissions, they can clear the security log, leaving you without a trail of their actions. If you use a tool that regularly collects and saves security log entries across your organization, even if intruders or administrators clear the local security log, you are more likely to be able to trace the actions of intruders or administrators. Microsoft Operations Manager is an example of such a tool. For the most recent tools available, see Search Microsoft.com at the Microsoft Web site.
Audit success and failure events in the system event category.
By auditing success and failure events in the system event category, you can notice unusual activity that may indicate that an intruder is attempting to gain access to your computer or your network.
The number of audits that are generated when this setting is enabled tends to be relatively low, and the quality of information that is gained from the events tends to be relatively high.
For information about the system event category, see Audit system events.
For information about how to enable auditing in the system event category, see Define or modify auditing policy settings for an event category.
Audit success events in the policy change event category on domain controllers.
If an event is logged in the policy change event category, someone has changed the Local Security Authority (LSA) security policy configuration.
If you use Group Policy to edit your auditing policy settings, it is not necessary to audit events in the policy change event category on member servers.
If you decide to audit failure events in the policy change event category, you can see if unauthorized users or attackers are trying to change policy settings, including security policy settings. Although this can be helpful for intrusion detection, the increase in resources that is required and the possibility of a denial-of-service attack usually outweigh the benefits.
For information about the policy change event category, see Audit policy change.
For information about how to enable auditing in the policy change event category, see Define or modify auditing policy settings for an event category.
Audit success events in the account management event category.
By auditing success events in the account management event category, you can verify changes that are made to account properties and group properties.
If you decide to audit failure events in the account management event category, you can see if unauthorized users or attackers are trying to change account properties or group properties. Although this can be helpful for intrusion detection, the increase in resources that is required and the possibility of a denial-of-service attack usually outweigh the benefits.
For information about the account management event category, see Audit account management.
For information about how to enable auditing in the account management event category, see Define or modify auditing policy settings for an event category.
Audit success events in the logon event category.
By auditing success events in the logon event category, you have a record of when each user logs on to or logs off from a computer. If an unauthorized person steals a user's password and logs on to a computer, you can determine when the breach of security occurred.
If you decide to audit failure events in the logon event category, you can see if unauthorized users or attackers are trying to log on to a computer. Although this can be helpful for intrusion detection, the possibility of a denial-of-service attack increases with the auditing of failure events in the logon event category. If you have failure auditing enabled in these event categories, users from outside of your organization can fill the security log or cause events to be overwritten by continuously attempting to log on to your network with incorrect usernames or passwords. If you also have the Audit: Shut down system immediately if unable to log security audits policy setting enabled, the consequences of logging failure events in these categories can be more severe - the user could cause a denial of service if the security log is filled.
For information about how to enable auditing in the logon event category, see Define or modify auditing policy settings for an event category.
Audit success events in the account logon event category on domain controllers.
By auditing success events in the account logon event category, you can see when users log on to or log off from the domain.
It is not necessary to audit events in the account logon event category on member servers.
If you decide to audit failure events in the account logon event category, you can see if unauthorized users or attackers are trying to log on to your network. Although this can be helpful for intrusion detection, the possibility of a denial-of-service attack increases with the auditing of failure events in the account logon event category. If you have failure auditing enabled in these event categories, users from outside of your organization can fill the security log or cause events to be overwritten by continuously attempting to log on to your network with incorrect usernames or passwords. If you also have the Audit: Shut down system immediately if unable to log security audits policy setting enabled, the consequences of logging failure events in these categories can be more severe - the user could cause a denial of service if the security log is filled.
For information about the account logon event category, see Audit account logon events.
For information about how to enable auditing in the account logon event category, see Define or modify auditing policy settings for an event category.
Be specific when setting up auditing on an object.
To audit object access, you must enable the Audit object access policy setting and then edit the system access control list (SACL) that is associated with the object. For more information, see Checklist: Setting up object access auditing.
For best system performance, minimize the number of entries in the SACL for an object. One entry in a SACL that contains 1000 users does not degrade system performance as much as 1000 separate entries.
To reduce the volume of events that is generated and to maximize the effectiveness of each event, only audit the actions that really interest you. For example, if you are interested in users reading a file, do not audit Full Control.
For information about the object access event category, see Audit object access.
For information about operation-based auditing, see Operation-based auditing on files or folders.
For information about how to enable auditing in the object access event category, see Define or modify auditing policy settings for an event category.
Set an appropriate size for the security log.
It is important that the size of the security log be configured appropriately, based on the number of events that your auditing policy settings generate.
For information about managing event logs, see Event Viewer.
For information about settings for the event logs, see Settings for Event Logs.