Defining a Baseline Audit Policy
Pages: 1, 2
I disagree with this thinking on three points:
- Failure auditing is an essential part of tracking unauthorized attempts to perform system actions or modify system resources. I would change "success" to "success, failure" wherever it occurs in the table shown previously.
- While WFP helps protect key system files, it doesn't protect everything. I would recommend enabling success and failure auditing for object access and then selectively configuring SACLs on key files on %systemdrive% and in the %systemroot% and %systemroot%\system32 folders.
- Finally, I would also recommend enabling the failure auditing of privilege use. Even though this is useful mainly for troubleshooting purposes, it also records attempts to load or unload device drivers, which attackers sometimes try to use to inject hostile code into the operating system. The auditing of privilege use also monitors attempts to take ownership of objects or run processes as part of the operating system; such events can also be signs of an attempted takeover of a system.
A better audit policy for a domain controller might look like this:
|Audit category||Default audit setting|
|Account log-on events||Success, failure|
|Account management events||Success, failure|
|Directory service access||Success, failure|
|Log-on events||Success, failure|
|Object access||Success, failure|
|Policy change||Success, failure|
|Process tracking||No auditing|
|System events||Success, failure|
And in fact, just such an audit policy is recommended by the Microsoft Windows Security Resource Kit.
Security Configuration Wizard
The Security Configuration Wizard (SCW) of Service Pack 1 for Windows Server 2003 can also be used to strengthen the audit policy on servers. SCW provides you with three options for defining an audit policy: no auditing, audit successful activity (the default), and audit successful and unsuccessful activity (Figure 1):
Figure 1. Using the SCW to configure auditing
The table below shows the audit policy configured for the second and third options:
|Audit category||Audit successful activity||Audit successful and unsuccessful activity|
|Account log-on events||Success, failure||Success, failure|
|Account management events||Success||Success, failure|
|Directory service access||Success||Success, failure|
|Log-on events||Success, failure||Success, failure|
|Object access||Success||Success, failure|
|Policy change||Success||Success, failure|
|Privilege use||No auditing||No auditing|
|Process tracking||Success||Success, failure|
|System events||Success, failure||Success, failure|
Comparing the these two options with the default and recommended audit policies for domain controllers discussed previously, we can see that the second option (audit successful activity) is stronger than the default policy but weaker than the one recommended by the Security RK. We also see that the third option is close to the policy recommended in the Security RK but differs in two important aspects. First, the policy created by the SCW doesn't audit failure of privilege use, which we saw can be useful for detecting certain kinds of attacks. Second, the SCW-created policy audits both success and failure for process tracking events. This is not a good idea because it will flood your security log with events generated whenever any process initiates or terminates, when handles are duplicated, and when numerous other low-level process events occur. It's difficult to see how any useful threat information can be extracted from such a flood of information.
One thing the SCW does is configure SACLs on operating system files so that object access auditing can collect useful information. So using the SCW to configure auditing on your SP1 domain controllers isn't a bad idea. You just may want to change the auditing of process tracking to No Auditing afterward and also change the auditing of privilege use to Failure. You can accomplish this by modifying the audit policy section of the Default Domain Controllers Policy GPO to make these two audit categories configurable in the LGPO on the domain controllers.
Return to the Windows DevCenter.