Audit Policy

Applies To: Windows Server 2008

Establishing an organizational computer system audit policy is an important facet of information security. Configuring Audit policy settings that monitor the creation or modification of objects gives you a way to track potential security problems, helps to ensure user accountability, and provides evidence in the event of a security breach.

There are nine different kinds of events for which you can specify Audit Policy settings. If you audit any of these kinds of events, Windows® records the events in the Security log, which you can find in Event Viewer.

• Account logon events. Audit this to record each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account. Account logon events are generated in the domain controller's Security log when a domain user account is authenticated on a domain controller. These events are separate from logon events, which are generated in the local Security log when a local user is authenticated on a local computer. Account logoff events are not tracked on the domain controller.

• Account management. Audit this to record when someone has changed an account name, enabled or disabled an account, created or deleted an account, changed a password, or changed a user group.

• Directory service access. Audit this to record when someone accesses an Active Directory® Domain Services object that has its own system access control list (SACL).

• Logon events. Audit this to record when someone has logged on or off your computer (either while physically at your computer or by trying to log on over a network).

• Object access. Audit this to record when someone has used a file, folder, printer, or other object. Although you can also audit registry keys, we do not recommend auditing them unless you have advanced computer knowledge and know how to use the registry.

• Policy change. Audit this to record attempts to change local security policies and to see if someone has changed user rights assignments, auditing policies, or trust policies.

• Privilege use. Audit this to record when someone performs a user right.

• Process tracking. Audit this to record when events such as program activation or a process exiting occur.

• System events. Audit this to record when someone has shut down or restarted the computer, or when a process or program tries to do something that it does not have permission to do. For example, if malicious software tried to change a setting on your computer without your permission, system event auditing would record it.

When you implement Audit Policy settings:

• Specify the categories of events that you want to audit. The event categories that you select constitute your audit policy.

• Set the size and behavior of the Security log. You can view the Security log with Event Viewer.

• If you want to audit directory service access or object access, determine which objects you want to audit access of and what type of access you want to audit. For example, if you want to audit all attempts by users to open a particular file, you can configure audit policy settings in the object access event category so that both successful and failed attempts to read a file are recorded.

The Security log records an audit event whenever users perform certain specified actions. For example, the modification of a file or a policy can trigger an event that shows the action that was performed, the associated user account, and the date and time of the action. These events can be both successful and failed attempts to perform actions.

Regular security analyses enable administrators to track and determine whether adequate security measures are in effect for each computer as part of an enterprise risk management program. Such analyses focus on highly specific information about all aspects of a computer that relate to security, which administrators can use to adjust the security levels. More important, this information can help detect any security oversights that may occur in the computer over time. For example, security levels may be temporarily changed to enable immediate resolution of an administration or network issue. However, such changes are often forgotten and never undone. If security levels are not properly reset, a computer may no longer meet the requirements for enterprise security.

Establishing and enabling audit policy settings that record deviations from your enterprise security policy are extremely important for any enterprise network. Audit logs may provide the only indication that a security breach has occurred by recording changes on file permissions, installation of programs, and escalation of privileges. If the breach is discovered some other way, proper audit settings can generate an audit log that may contain important information about the breach, how it occurred, and what systems were affected.

In many cases, failure events are much more informative than success events because failures typically indicate errors. For example, successful logon to a computer by a user would typically be considered normal. However, if someone unsuccessfully tries to log on to a computer multiple times, it may indicate an attacker's attempt to break into the computer with someone else's account credentials. The Event Log item of Group Policy is used to define attributes that relate to the Application, Security, and System logs, such as maximum log size, access rights for each log, and retention settings and methods. Auditing events are stored in the Security event log. For more information about the Event Log, see the Event Log section in this guide.

Before any audit processes are implemented, an organization should determine how to collect, organize, and analyze the data. There is little value in large volumes of audit data if there is no underlying plan to use it. Also consider that audit settings can affect computer performance. The effect of a given combination of settings may be negligible on an end-user computer but quite noticeable on a busy server. Therefore, you should perform some performance tests before you deploy new audit settings in your production environment. A final consideration is the amount of storage space that you can allocate to store the data collected during auditing. Depending on the setting you choose, auditing data can accumulate quickly and can fill up available disk space.

You can configure the Audit Policy settings in the following location within the Group Policy Management Console in Windows Vista with Service Pack 1 (SP1) and in Windows Server 2008:

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

The following sections describe the options and issues for configuring Audit Policy settings for better system management and security.

Audit Policy settings

The vulnerabilities, countermeasures, and potential impacts of all the Audit Policy settings are identical. The options for each of the audit settings are also identical:

• Success. An audit event is generated when the requested action succeeds.

• Failure. An audit event is generated when the requested action fails.

• No Auditing. No audit event is generated for the associated action.

Vulnerability

If Audit Policy settings are not configured, it can be difficult or impossible to determine what occurred during a security incident. However, if Audit Policy settings are configured so that events are generated for all activities, the Security log will be filled with data and hard to use. Also, you can use a large amount of data storage as well as adversely affect overall computer performance if you configure Audit Policy settings for a large number of objects.

If failure auditing is used and the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is enabled, an attacker could generate millions of failure events such as logon failures in order to fill the Security log and force the computer to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten, an attacker can overwrite part or all of their activity by generating large numbers of events so that the evidence of their intrusion is overwritten.

Countermeasure

Enable Audit Policy settings that support the organizational security policy for all the computers in your organization. Identify the components that you need to monitor to enable your organization to hold users accountable for their actions while they use organizational resources, enables IT departments to detect unauthorized activity efficiently, and tracks those events in log files.

Potential impact

If no Audit Policy settings are configured or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too detailed, critically important entries in the Security log may be obscured by the large number of log entries created by routine activities and computer performance, and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.

Audit account logon events

This policy setting enables auditing of each instance of user logon or logoff on a different computer than the one that records the event and validates the account. Success audits provide useful information for accounting purposes and for post-incident forensics so that you can determine who successfully logged on to which computer.

Failure audits are useful for intrusion detection. However, this configuration of the policy setting also creates the potential for a DoS attack. When the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is also enabled, an attacker could generate millions of logon failures in order to fill the Security log and force the computer to shut down.

If you configure the Audit account logon events setting to Success on a domain controller, an event is logged for each user who is validated against that domain controller, even though the user actually logs on to a workstation or server that is joined to the domain.

By default, Auditaccount logon events is set to Success.

Audit account management

This policy setting enables auditing of each account management event on a computer. Examples of account management events include the following:

• User account or group is created, changed, or deleted.

• User account is renamed, disabled, or enabled.

• Password is set or changed.

Success audits should be enabled on all computers in your enterprise. When an organization responds to security incidents, it is critical that they be able to track who created, changed, or deleted an account. Failure audits generate an event when any account management action fails.

Audit directory service access

This policy setting enables auditing of user access of an Active Directory object that has an associated SACL. A SACL is list of users and groups for which actions on an object are to be audited on a Windows–based network.

Success audits generate an event when a user successfully accesses an Active Directory object that has a SACL that indicates that the user should be audited for the requested action. Failure audits generate an event for each unsuccessful attempt. (Both types of events are created before the user is notified that the request succeeded or failed.) If you enable this policy setting and configure SACLs on directory objects, a large volume of entries can be generated in the Security logs on domain controllers. You should enable these settings only if you actually intend to use the information that is created.

Audit logon events

This policy setting enables auditing of each instance of user logon, logoff, or network connection to the computer that records the event. If you log successful account logon events on a domain controller, workstation logon attempts do not generate logon events. Only interactive and network logon attempts to the domain controller itself generate logon events on the domain controller. To summarize, "account logon events" are generated where the account exists, either on the domain controller if the account is a domain account or on the local computer if the account is a local computer account, and "logon events" are generated on the computer where the user is logging on or off.

Success audits provide useful information for accounting purposes and for post-incident forensics so that you can determine who successfully logged on to which computer. Failure audits are useful for intrusion detection. However, the configuration of failure events also creates a potential DoS condition. When the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is also enabled, an attacker could generate millions of logon failures in order to fill the Security log, and force the server to shut down.

Audit object access

This policy setting enables auditing of the event generated by a user who accesses an object—for example, a file, folder, registry key, or printer—that has a SACL that specifies a requirement for auditing.

Success audits generate an event when a user successfully accesses an object that has a SACL. Failure audits generate an event for each unsuccessful attempt (some failure events are to be expected during normal computer operations). For example, many applications (such as Microsoft Office Word) always attempt to open files with both read and write privileges. If the applications are unable to do so, they then try to open the files with read-only privileges. If you enable failure auditing and the appropriate SACL on the file, a failure event is recorded when such an event occurs.

You can audit access to objects that are stored in the Internet Information Services (IIS) metabase. To enable metabase object auditing, you must enable Audit object access on the target computer and then set SACLs on the specific metabase objects whose access you want to audit.

If you configure the Audit object access policy setting and configure SACLs on objects, a large volume of entries can be generated in the Security logs on computers in your organization. Therefore, you should only enable these settings if you actually intend to use the information that is logged.

Audit policy change

This policy setting enables auditing of every incidence of a change to user rights assignment policies, Windows Firewall policies, Audit policies, or trust policies.

Success audits are useful for accounting purposes and can help you determine who successfully modified policies in the domain or on individual computers. Failure audits generate an event when a change to user rights assignment policies, Audit policies, or trust policies fails.

If you enable the Audit policy change setting in Windows Vista and Windows Server 2008, logging of configuration changes for the Windows Firewall component is also enabled.

Audit privilege use

This policy setting enables auditing of each instance of a user who exercises a user right.

Success audits generate an event when the exercise of a user right succeeds. Failure audits generate an event for an unsuccessful exercise. If you enable this policy setting, the volume of events that is generated can be very large and cumbersome. You should enable this setting only if you plan to use the information that is generated.

Audit events are not generated for the use of the following user rights, even if success audits or failure audits are specified for the Audit privilege use policy setting:

• Bypass traverse checking

• Debug programs

• Create a token object

• Replace process level token

• Generate security audits

• Backup files and directories

• Restore files and directories

Audit process tracking

This policy setting enables auditing of detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.

Success audits generate an event when the process being tracked succeeds. Failure audits generate an event when the process fails.

If you enable Audit process tracking in Windows Vista and Windows Server 2008, Windows also logs information about the operating mode and status of the Windows Firewall component.

When enabled, the Audit process tracking setting generates a large number of events. This policy setting is typically configured to No Auditing. However, the information that this policy setting generates can be very beneficial during an incident response because it provides a detailed log of the processes that were started and when they were started.

Audit system events

This policy setting enables auditing of the restart or shutdown of users' computers, or events that affect either computer security or the Security log.

Success audits generate an event when an event runs successfully. Failure audits generate an event when an event is unsuccessful.

Because few additional events are recorded if both failure and success audits are enabled for system events, and because all such events are very significant, you should configure this policy setting to Enabled on all computers in your organization.

Audit example: Results of a user logon event

After you become familiar with the audit settings in Windows, it may be helpful to consider a specific example. The audits in this example are performed from an individual computer's perspective, rather than from the more holistic perspective that an enterprise administrator might prefer. Because events are recorded on individual computers, you might need to examine the Security logs of multiple computers and correlate the data to determine what occurred.

The following tables show the core events that are written to the event logs of an end-user computer, a file server, and a domain controller, when an authorized user logs on to his or her computer and accesses a file in a shared folder hosted by the file server. Only the core events are documented—other events that are generated by these activities were omitted for the sake of clarity. The names of the accounts and resources involved in this example are:

• Domain = Contoso

• Domain controller = DC1

• File server = FS1

• End-user computer = XP1

• User = John

• Shared folder on FS1 = Share

• Document in the shared folder = document.txt

User Action 1: User logs on to his or her computer

User Action 2: User connects to the shared folder called Share

User Action 3: User opens the file document.txt

User Action 4: User saves the file document.txt

Although this example may look like a complex series of events, it has been greatly simplified. The listed actions would actually generate dozens of logon, logoff, and privilege use events on the domain controller and file server. When the user opens the file, scores of object access events are also generated, and each time the user saves the file many more events are generated.

Per-user Selective Auditing

Available in Windows Vista, Windows Server 2008, Windows Server 2003, and Windows XP with Service Pack 2 (SP2), per-user selective auditing allows for selective audit levels on individual user accounts. For example, audit levels can be set to report only logon and logoff activity for all users while auditing all activity for a specific user. Per-user selective audit can also be used to reduce the volume of events in the Security log by allowing certain accounts to be excluded from audit generation for certain activities. Only user accounts can be audited using this functionality; security and distribution groups cannot be audited. Accounts that belong to the local Administrators group cannot be excluded from auditing by using the per-user selective audit mechanism.

Valid selective auditing categories are:

• Account Logon

• Account Management

• Directory Service Access

• Detailed Tracking

• Logon/Logoff

• Object Access

• Policy Change

• Privilege Use

• System Event

In Windows Vista and Windows Server 2008, the command-line tool used to set per-user auditing policy for selective auditing is Auditpol. For a command-line reference on the use of Auditpol, see Auditpol (https://go.microsoft.com/fwlink/?LinkID=84473).

Expanded Auditing Policy in Windows Vista and Windows Server 2008

In Windows Vista and Windows Server 2008, auditing has been expanded to support auditing subcategories for each of the categories discussed in the previous section. These subcategories allow you to fine-tune your auditing strategy to reduce the number of extraneous entries in the auditing logs and allow each organization to focus their auditing on the events that are important to them.

If you are going to use auditing subcategories, you should not use Group Policy to define and distribute your auditing policies. The Group Policy Management Console configures only the top-level auditing categories and enables all of the subcategories within the category and thus cannot be used to set more targeted audit policy. Instead, auditing policy that uses auditing subcategories must be defined by using the command-line tool auditpol.exe and distributed by means of a script.

The following table identifies the auditing subcategories:

For instruction on how to use auditpol.exe to create detailed audit policies for computers running Windows Vista and how to distribute those setting by using a script, see article 921469, "How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain" (https://go.microsoft.com/fwlink/?LinkID=82447).

Additional references

The following links provide additional information about topics that relate to Audit policy settings for computers that run Windows Vista or Windows Server 2008:

• For more Audit policy information, see "Security Auditing" in the Windows Server 2008 Technical Library (https://technet.microsoft.com/en-us/library/cc771395.aspx).

• For an overview of Windows Server 2008 auditing and compliance issues, see the TechNet magazine article "Auditing and Compliance in Windows Server 2008."

• Article 921469, "How to use Group Policy to configure detailed security auditing settings for Windows Vista-based and Windows Server 2008-based computers in a Windows Server 2008 domain, in a Windows Server 2003 domain, or in a Windows 2000 domain"(https://go.microsoft.com/fwlink/?LinkID=82447) describes a procedure that administrators can use to deploy a custom audit policy that applies detailed security auditing settings for Windows Vista and Windows Server 2008-based computers.

• Article 947226, "Description of security events in Windows Vista and in Windows Server 2008" (https://support.microsoft.com/kb/947226/en-us) describes various security-related and auditing-related events in Windows Vista and in Windows Server 2008. This article also provides information about how to interpret these events. All these events appear in the Security log and are logged with a source of "Security-Auditing. This information can also be downloaded as a reference spreadsheet "Security audit events for Windows Server 2008 and Windows Vista: from the Download Center (https://www.microsoft.com/downloads/details.aspx?FamilyID=82E6D48F-E843-40ED-8B10-B3B716F6B51B&displaylang=en)

• Article 947223, "Description of the Special Groups feature in Windows Vista and in Windows Server 2008" (https://support.microsoft.com/kb/947223/en-us) describes how to audit when members of identified special groups log on to the computer.