WindowsDevCenter.com
oreilly.comSafari Books Online.Conferences.

advertisement


AddThis Social Bookmark Button

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
Privilege use 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
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.

Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.


Return to the Windows DevCenter.