Defining a Baseline Audit Policy

Auditing for security events on critical computer systems is an essential component of a sound security policy. An audit policy is the portion of a Group Policy object (GPO) that defines which security events have success and/or failure actions audited and recorded in the Security log. A baseline audit policy is the minimum auditing you should perform on a given type of system. Let's examine the default audit policies for Windows Server 2003 server roles and see whether they are adequate for the security needs of a typical company.

Default Audit Policy on Member Servers

On a freshly installed Windows Server 2003 member server with no server roles defined, only two types of auditing are defined:

• Account log-on events: success auditing
• Log-on events: success auditing

All seven other audit categories (management events, directory service access, object access, policy change, privilege use, process tracking, and system events) are configured for no auditing. This makes sense for several reasons:

• In domain environments, most management events occur on domain controllers; for example, resetting passwords for domain accounts.
• Member servers don't have a copy of Active Directory, so auditing directory service access on them makes no sense.
• Policy is also usually configured on domain controllers, so auditing policy change on member servers makes little sense.
• Auditing of process tracking is used more for troubleshooting purposes than for maintaining security.
• Auditing of system events is used mainly for troubleshooting to record unexpected reboots and other operating system actions.

Related Reading Windows Server Hacks 100 Industrial-Strength Tips & Tools By MitchTulloch Table of Contents Index

Auditing log-on events and account log-on events on a member server does make sense, however. The difference between these two audit categories is that the auditing of account log-on events records the actions taken by authentication packages. If someone tries to log on to a member server using a local account, the authentication process is performed by the member server itself, and an event (success or failure audit) will be logged in the Security log on the member server. On the other hand, if somebody tries to log on to a member server using a domain account, the authentication process is performed by a domain controller, and an event is recorded in the Security log on the authenticating domain controller.

By contrast, the auditing of log-on events is designed simply to track which users are logging on to which computers on your network, whether interactively (on the local console) or remotely (network log on). Log-on events are always recorded in the security log of the computer where the user is trying to log on. So by auditing both log-on events and account log-on events on a member server, you can record all attempts to log on to the server and, especially, monitor any attempts to log on using local accounts. This is important because local accounts are generally not used in domain environments, so any attempt to log on to a server using a local account other than for troubleshooting purposes should raise a red flag of a possible intrusion attempt. Auditing account log-on events can help expose such attempts.

But is the default audit policy for member servers really good enough? You might also want to consider enabling success and failure auditing for policy change events, as this will detect any attempt to change the security policy on the server. And if you have critical data files on your server and want to track unauthorized attempts to access them, you can also enable failure auditing of object access and then configure SACLs (static access control lists) on the files you want to monitor. Finally, you might also want to audit both successes and failures for both log-on events and account log-on events; I'll explain why in a moment.

Default Audit Policy for Domain Controllers

The default audit policy on a Windows Server 2003 domain controller is more stringent than for member servers and looks like this:

Several ideas are most likely behind these default settings. One is that auditing privilege use and process tracking is of not much use since the information gained is mostly useful for troubleshooting purposes. Another is that auditing object access is not critical because Windows File Protection (WFP) guards operating system files, and domain controllers usually aren't used to store other business information the way file servers are. In addition, success auditing gives a good enough picture of how resources are used on domain controllers, and the failure auditing of these resources is therefore unnecessary.

[1] [2] Next