An Audit policy determines the security events to report to administrators so that user or system activity in specified event categories is recorded. The administrator can monitor security-related activity, such as who accesses an object, when users log on to or log off from computers, or if changes are made to an Audit policy setting. For all of these reasons, Microsoft recommends that you form an Audit policy for an administrator to implement in your environment.
However, before you implement an Audit policy you must decide which event categories need to be audited in your environment. The audit settings you choose within the event categories define your Audit policy. When you define audit settings for specific event categories, an administrator can create an Audit policy that will meet the security needs of your organization.
If no audit settings are configured, it will be difficult or impossible to determine what took place during a security incident. However, if audit settings are configured so that too many authorized activities generate events, the Security event log will fill up with useless data. The information in the following sections is designed to help you decide what to monitor and how to collect relevant audit data for your organization.
You can configure the Audit policy settings in Windows XP at the following location in the Group Policy Object Editor:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy
The following table summarizes the Audit policy setting recommendations for both desktop and laptop client computers in the two types of secure environments that are discussed in this chapter. The Enterprise Client environment is referred to as EC, and the Specialized Security – Limited Functionality environment is referred to as SSLF. You should review these recommendations and adjust them as appropriate for your organization. However, be very cautious about audit settings that can generate a large volume of traffic. For example, if you enable either success or failure auditing for Audit privilege use, so many audit events will be generated that it may not be feasible to find other types of entries in the Security event log. Such a configuration could also have a significant impact on performance. More detailed information about each of the settings is provided in the following subsections.
| Setting | EC desktop | EC laptop | SSLF desktop | SSLF laptop |
|---|---|---|---|---|
| Audit account logon events | Success | Success | Success, Failure | Success, Failure |
| Audit account management | Success | Success | Success, Failure | Success, Failure |
| Audit directory service access | Not Defined | Not Defined | Not Defined | Not Defined |
| Audit logon events | Success | Success | Success, Failure | Success, Failure |
| Audit object access | No Auditing | No Auditing | Failure | Failure |
| Audit policy change | Success | Success | Success | Success |
| Audit privilege use | No Auditing | No Auditing | Failure | Failure |
| Audit process tracking | No Auditing | No Auditing | No Auditing | No Auditing |
| Audit system events | Success | Success | Success | Success |
Audit account logon events
If this policy setting is enabled, events for credential validation are generated. These events occur on the computer that is authoritative for the credentials. For domain accounts the domain controller is authoritative, and for local accounts the local computer is authoritative. In domain environments, most of the Account Logon events occur in the Security log of the domain controllers that are authoritative for the domain accounts. However, these events can occur on other computers in the organization depending on the accounts that are used to log on.
In this guidance, the Audit account logon events setting is configured to Success only for the EC environment and to Success and Failure for the SSLF environment.
Audit account management
This policy setting is used to track attempts to create new users or groups, rename users or groups, enable or disable user accounts, change account passwords, and enable auditing for Account Management events. If you enable this Audit policy setting, administrators can track events to detect malicious, accidental, and authorized creation of user and group accounts.
The Audit account management setting is configured to Success for the EC environment and to Success and Failure for the SSLF environment.
Audit directory service access
This policy setting can only be enabled to perform audit tasks on domain controllers. For this reason, the setting is not defined at the workstation level. This policy setting does not apply to computers that run Windows XP Professional. Therefore, ensure that the Audit directory service access setting is configured to Not Defined for the two environments that are discussed in this chapter.
Audit logon events
This policy setting generates events that record the creation and destruction of logon sessions. These events occur on the computer that is accessed. For interactive logons, these events would be generated on the computer that was logged on to. If a network logon was performed to access a share, these events would be generated on the computer that hosts the resource that was accessed.
If you configure the Audit logon events setting to No auditing, it is difficult or impossible to determine which user has either accessed or attempted to access computers in the organization.
The Audit logon events setting is configured to log Success events for the EC environment. This policy setting is configured to Success and Failure events for the SSLF environment.
Audit object access
By itself, this policy setting will not cause any events to be audited. It determines whether to audit the event of a user who accesses an object - for example, a file, folder, registry key, or printer - that has a specified system access control list (SACL).
A SACL is comprised of access control entries (ACEs). Each ACE contains three pieces of information:
- The security principal (user, computer, or group) to be audited.
- The specific access type to be audited, called an access mask.
- A flag to indicate whether to audit failed access events, successful access events, or both.
If you configure the Audit object access setting to Success, an audit entry is generated each time that a user successfully accesses an object with a specified SACL. If you configure this policy setting to Failure, an audit entry is generated each time that a user unsuccessfully attempts to access an object with a specified SACL.
Organizations should define only the actions they want enabled when they configure SACLs. For example, you might want to enable the Write and Append Data auditing setting on executable files to track when they are changed or replaced, because computer viruses, worms, and Trojan horses typically target executable files. Similarly, you might want to track when sensitive documents are accessed or changed.
The Audit object access setting is configured to No Auditing for the EC environment and to Failure for the SSLF environment. You must enable this setting for the following procedures to take effect.
The following procedures detail how to manually set up audit rules on a file or folder and how to test each audit rule for each object in the specified file or folder. The testing procedure may be automated by means of a script file.
To define an audit rule for a file or folder
- Locate the file or folder using Windows Explorer and select it.
- Click the File menu and select Properties.
- Click the Security tab, and then click the Advanced button.
- Click the Auditing tab.
- Click the Add button, and the Select User, Computer, or Group dialog box will display.
- Click the Object Types... button, and in the Object Types dialog box select the object types you want to find.
Note: The User, Group, and Built-in security principal object types are selected by default. - Click the Locations... button, and in the Location: dialog box select either your domain or local computer.
- In the Select User or Group dialog box, type the name of the group or user you want to audit. Then, in the Enter the object names to select dialog box, type Authenticated Users (to audit the access of all authenticated users) and click OK. The Auditing Entry dialog box will display.
- Determine the type of access you want to audit on the file or folder using the Auditing Entry dialog box.
Note:Remember that each access may generate multiple events in the event log and cause it to grow rapidly. - In the Auditing Entry dialog box, next to List Folder / Read Data, select Successful and Failed, and then click OK.
- The audit entries you have enabled will display under the Auditing tab of the Advanced Security Setting dialog box.
- Click OK to close the Properties dialog box.
To test an audit rule for the file or folder
- Open the file or folder.
- Close the file or folder.
- Start the Event Viewer. Several Object Access events with Event ID 560 will appear in the Security event log.
- Double-click the events as needed to view their details.
Audit policy change
This policy setting determines whether to audit every incident of a change to user rights assignment policies, Windows Firewall policies, Trust policies, or changes to the Audit policy itself. The recommended settings would let you see any account privileges that an attacker attempts to elevate - for example, by adding the Debug programs privilege or the Back up files and directories privilege.
The Audit policy change setting is configured to Success for the two environments that are discussed in this chapter. The setting value for Failure is not included because it will not provide meaningful access information in the Security event log.
Audit privilege use
This policy setting determines whether to audit each instance of a user exercising a user right. If you configure this value to Success, an audit entry is generated each time that a user right is exercised successfully. If you configure this value to Failure, an audit entry is generated each time that a user right is exercised unsuccessfully. This policy setting can generate a very large number of event records.
The Audit privilege use setting is configured to No Auditing for computers in the EC environment and to Failure for the SSLF environment to audit all unsuccessful attempts to use privileges.
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. Enabling Audit process tracking will generate a large number of events, so typically it is set to No Auditing. However, this setting can provide a great benefit during an incident response from the detailed log of the processes started and the time when they were launched.
The Audit process tracking setting is configured to No Auditing for the two environments that are discussed in this chapter.
Audit system events
This policy setting is very important because it allows you to monitor system events that succeed and fail, and provides a record of these events that may help determine instances of unauthorized system access. System events include starting or shutting down computers in your environment, full event logs, or other security-related events that affect the entire system.
The Audit system events setting is configured to Success for both of the environments that are discussed in this chapter.