Recipe11.2.Enabling Auditing

Recipe 11.2. Enabling Auditing

Problem

You want to enable auditing to track certain types of activity that can be useful should you need to backtrack later to determine the cause of security-related issues (e.g., user accidentally deleted, account being compromised).

Solution

Using a graphical user interface

Open the Local Security Policy snap-in.
In the left pane, expand Local Policies Audit Policy.
In the right pane, double-click the setting you want to enable, and check the box beside Success and/or Failure depending on the types of events you want to audit.

You can force new auditing settings to be applied by running the secedit command on Windows 2000 or the gpupdate command on Windows Server 2003.

Run the following command on Windows 2000:

> secedit /refreshpolicy machine_policy

And run this command on Windows Server 2003:

> gpupdate /target:computer

Discussion

Windows supports auditing of various account- and system-related events, which can be invaluable when troubleshooting a security incident. You can enable auditing of nine different types of access on a local server. You can also configure these settings via an Active Directory group policy, which overrides any local settings that you've defined. After auditing has been configured, audit messages are created in the Security event log.

The big question is: which audit settings should you enable? If you turned on everything, your server would start flooding your Security event log and ultimately it wouldn't be very useful. In fact, there are no hard and fast rules for which settings you should enable.

All audit settings have three possible configurations: not configured, Success, and Failure. Not configured means auditing isn't enabled for the setting, Success means log any applicable event that was successful, and Failure means log any applicable event that failed. Often, it is more useful to log Failure events since you want to discover someone who is attempting to perform an activity surreptitiously, which may mean doing it several times until successful.

With some settings, simply enabling Success or Failure won't actually cause any events to be logged. You also have to enable auditing on specific objects, such as a particular file, before events will be audited. This is useful because in some cases, such as files and folders, you may only want to audit certain ones. If auditing were enabled for all files, the amount of events would render auditing unfeasible.

I've listed each of the nine settings in Table 11-1, including information about what type of information is logged and my recommendation for whether you should consider enabling it.

Table 11-1. Audit policy settings
Audit setting	Access type	Recommendation
Account Logon Events	User account log on and log off attempts that are validated by this system.	This setting is most often used on domain controllers, which are generally responsible for authenticating users in a domain environment. Be careful when enabling this because of the large number of events that might be logged.
Account Management	Creation, modification, and deletion of user, group, and computer accounts. Also includes password changes.	Consider enabling both Success and Failure auditing for this setting on member servers, which generally shouldn't have too much account management activity. For domain controllers, you may only want to enable Failure, due to the high number of account management activities.
Directory Service Access	Any type of read or write access to an object in Active Directory.	After enabling this setting, you must also modify the SACL of the object you want to audit. Be careful enabling this on a large container or commonly accessed object in the directory because it can generate a lot of events quickly.
Logon Events	User account log on and log off attempts, and the initiation of network connections.	Unlike the Account Logon Events setting, this setting logs the events on the computer that the request is being made on, not necessarily the computer that is validating the accounts involved. Depending on how busy your servers are, this setting may generate a large number of events.
Object Access	Any type of read or write access to an object on the system (file, folder, printer, registry key, etc.).	After enabling this setting, you must also modify the SACL of the object you want to audit. Be careful enabling this on a frequently accessed object because it can generate a lot of events quickly.
Policy Change	Change to user right policies, audit policies, and trust policies.	Since the number of policy changes is generally low, you might want to consider enabling both Success and Failure auditing for this setting.
Privilege Use	User exercising a user right (e.g., act as part of the operating system, access this computer from the network, log on as a service).	Enabling either Success or Failure for this setting can generate a lot of events, so enable them only if explicitly needed.
Process Tracking	Process creation and termination, and other process-related activities.	Since processes are created and terminated frequently, enabling Success or Failure for this setting can generate a lot of events. Enable it only if explicitly needed.
System Events	System restart or shutdown, and modifications to system security or the security event log.	Since the number of these type of events should be relatively low, consider enabling both Success and Failure.

Be sure to thoroughly test any audit settings before implementing them in production. Even after implementing a change in production, periodically monitor the Security event log to ensure the log isn't being flooded with events.