Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Establishing a Windows Server 2003 Audit Policy for the Forest

An audit policy is more than the configuration of a Group Policy Audit Policy and associated logs. Because Group Policy automates the implementation of security event collection, designing and implementing such a policy is a good first step in building a more comprehensive audit policy for your enterprise. Audit Policy is a part of the Security Settings section of Group Policy and, therefore, can be quickly configured and implemented across an entire domain. Learning the basics of configuration and interpretation of the events collected can help you determine what else is needed while you are benefiting from what you have quickly and easily implemented.

WARNING: Don't Configure Audit Policy Blindly

Use caution when implementing Audit Policy. You can easily collect more data than can easily be reviewed, and if you have not properly configured the Security Event Log and your policies for managing events, this data collection can overwhelm or even halt a system's operation. Audit Policy, like many Windows Server 2003 security features, can be quickly implemented, providing you with excellent benefits or with complete disaster. Spend some time learning about what you are doing and planning how the system will operate and how the data will be used.

Audit Policy is configured by default for Windows Server 2003 domain controllers. (Auditing is not turned on by default in previous releases of Windows.) An audit policy capable of producing comprehensive security log data has been available since the beginning of Windows NT. Although it may be argued that the collection of an audit trail is by itself not a sound security practice (you have to use the data in order for it to be effective), the default collection of this data is valuable in the following ways:

After an intrusion or other security incident, the existence of audit records may be useful to determine what happened.

Audit records may provide prosecutorial evidence of fraud, theft, or other illegal activities.

Audit records may provide internally acceptable proof of non-compliance to organization policy.

Because IT personnel are trained in the use of computer logs for monitoring and troubleshooting performance and other production issues, the availability of security-related information can assist them in these efforts (for example, in troubleshooting logon issues).

Curiosity on the part of IT personnel who may examine log information can inadvertently bring to light security issues or evidence of intrusion, and better security practices can be developed as risks to operation are exposed.

Audit Policy Basics

In a Windows Server 2003 domain, Audit Policy settings are configured in the Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy section of a GPO. When this policy is configured, it applies to the computers whose accounts are within the container to which the GPO is linked. Security events are logged to the Security Event Log of the computer within which the event occurred. The Audit Policy in the Default Domain Controller GPO, as shown in Figure 18-1, is configured by default. However, there are no settings for the Default Domain GPO. Therefore, while some audit information is logged to the security event log on each DC, events are not logged for other computers joined to the domain.

Figure 18-1. The default Audit Policy for the domain controller's OU.

[View full size image]

To configure Audit Policy for the domain, do the following:

Determine which computers need to have auditing turned on.

Determine which Audit Policy settings are relevant for different computers.

Configure an audit policy for adoption by domain members.

Configure an event log policy. Event logs are unusual files; they cannot infinitely grow until all disk space is consumed. Instead, a maximum event log size is configured along with instructions on what to do when the event log reaches maximum size.

Configure other audit and event log-related Security Options in Group Policy.

Determining Which Computers to Audit and Which Events to Collect

It is easy to suggest that you should turn on auditing for all computers, but in most environments, this is impractical. Certainly, all domain controllers, all servers, and those workstations in sensitive areas or where sensitive data is stored or from which it is accessed should have auditing tuned on. Examples of sensitive servers are mail servers, firewalls, web servers, database servers, and other servers that are part of critical or sensitive operations. For example, if an n-tier application (an applications whose components are spread across multiple computers) such as an e-commerce, customer relationship management, or distribution application is in operation, all computers involved in the application should be audited. Before blindly enabling auditing on these computers for full event collection, you should, of course, consider the impact on performance and on default user rights and permissions set by these applications. For example, auditing account logon events on Exchange servers may produce so many events that it has a very bad impact on performance.

Determine and Configure Audit Policy

The default Domain Controllers policy does have auditing configured, but is it right for your organization? What other policies need to be configured? The default Domain Controllers policy should be adjusted to meet your auditing needs for DCs. In addition, when you have decided which events should be collected at various servers and workstations, configure those policies within a GPO linked to the OU within which the computer account resides. Although it's possible to configure the Audit Policy for all computers in the domain by configuring the Audit Policy in a GPO linked to the domain object, this may not be practical either because security log entries will be so numerous as to never be reviewed, or because Audit Policy settings need to be configured differently for computers that play different roles on the network. If standalone computers are part of your organization, you must configure a local audit policy within the Local Security Policy console or by using the Group Policy snap-in.

On a standalone Windows Server 2003 computer, Audit Policy settings can be set to

Success

Failure

Success and failure

No auditing

In a GPO, Audit Policy settings can be one of the following:

Not configured

No auditing

Success

Failure

Success and failure

Normal GPO hierarchical rules apply. A setting of Not configured means no selection. An Audit Policy set higher in the OU hierarchy or at the site or domain level will be unaffected by a GPO that specifies Not configured. No auditing, on the other hand, explicitly turns off auditing, and if the GPO within which it is located is closer to the computer account, it will override earlier settings. To change settings, double-click the policy to open its Property page and select or deselect the desired option. Audit policies are listed and described in Table 18-1.

Table 18-1. Audit Policies
Audit Policy	Purpose
`Audit account logon events`	To record logon events at the DC. Kerberos events are also recorded.
`Audit account management`	To record changes to user, group, and computer accounts. Records account creation and deletion, password changes, and group membership changes.
`Audit directory service access`	To enable logging of Active Directory object access. Some objects are already configured. Configure settings on specific objects in the Active Directory. To record those events in the Security log, you must turn object auditing on at this policy.
`Audit logon events`	To record logon events at the console where logon occurs. When IPSec negotiate policies are used, IKE events are also recorded, as are SID filtering events.
`Audit object access`	To enable logging of access to files, folders, registry keys, and printers if specific objects are configured for auditing.
`Audit policy change`	To record changes to the audit policy and Kerberos policy as well as to user rights, trust relationships, and the IPSec agent.
`Audit privilege use`	To record privileges added to the user's access token, and the use of these privileges. Multiple events may be recorded for each privilege use.
`Audit process tracking`	To record processing activity including process creation and exit, access to objects, backup and recovery of the data protection master key, installation of services, and creation of scheduled jobs. In most environments, this policy should not be set because it can generate massive amounts of events. In a development environment, this can be a useful policy because it can help the developer see what his code is actually doing.
`Audit system events`	To record startup and shutdown events, loading of authentication packages, clearing the audit log, and changes to the system time.

Table 18-2 provides recommendations for Audit Policy settings for domain controllers. Note that it varies from the default in most instances by adding the Failure setting. You should consider if this is right for you. The rationale for setting Failure is to generate those events that may aid in detecting attacks. For example, if failed logon events are captured, they may be simple user forgetfulness or fumble fingers; still, a larger number of failed logon events may mean an attack. Some recommend recording only failure events; after all, who wants to review successful logons? However, if successful logons are not recorded, and a large number of failure events are recorded but then stop, how will you determine if an attacker gave up or was successful in compromising the account? Another reason for recording successful logon is to be able to determine the timeframe within which a specific user was logged on. If you are trying to determine who might have performed some action on a system, knowing that an individual was or was not logged on is very useful.

Table 18-2. Audit Policy Recommendations
Audit Policy	Default	Recommendation
`Audit account logon events`	Success	Success, Failure
`Audit account management`	Success	Success, Failure
`Audit directory service access`	Success	Success, Failure
`Audit logon events`	Success	Success, Failure
`Audit object access`	Success	Success, Failure
`Audit policy change`	Success	Success, Failure
`Audit privilege use`	No Auditing	No Auditing or Not Configured
`Audit process tracking`	No Auditing	No Auditing or Not Configured
`Audit system events`	Success	Success, Failure

Audit Policy, like many security settings, should be considered for each computer role on the network. Although it may be impractical to collect and examine all the possible audit records on all computers, an appropriate policy for each computer role should be developed. Settings for other member computers may need to be adjusted according to the sensitive nature of the data or computer role on the network. For example, developer computers may want to set Audit process tracking.

Interpreting Audit Policy Events

After Audit Policy is configured, a lot of information will be collected. To be of value, it must be used. If security logs are reviewed in real time, they can provide evidence of an ongoing attack or can reveal a weakness that requires immediate correction. Archival records of activity on the server can provide evidence and establish accountability after the fact. Some activity may only be noticed when reviewing activity in the logs over time. By looking at the events over a period of hours or days, a pattern may emerge, or you may find a more sinister reason for some seemingly innocent behavior. The first step in learning how to use log data is to be able to understand the events that are being recorded there. Table 18-3 provides a list of security events that may be found in the security event log and how they might be interpreted.

Table 18-3. Suspicious Account Events
Event ID	Description	Possible Interpretation
675	Pre-authentication failed.	User entered an incorrect domain account password.
644	A user account was automatically locked.	A user incorrectly entered his password too many times, or an attack against user accounts is/was underway. What is the number of failed attempts necessary to generate the lock? (What is the account lockout policy?) If the account lockout policy requires a large number of failures before the lockout, it's more likely that this event indicates an attack. Check the number of these events. A large number of these events may indicate an automated password cracking attack.
529	Logon failure. Unknown user name or bad password.	Depending on the number and frequency of these events, they may indicate a password cracking attack. Are there a large number of these events for specific accounts and for a large number of accounts? If so an attack is the likely explanation.
530	Logon Failure. Outside allotted time.	This might simply be the result of a workstation whose clock is not synchronized with the forest. It also could be an attack on Kerberos credentials.
531	Logon Failure. Disabled account.	Check the age of the account. If the account is disabled because it was just created, it might just mean that a new employee is attempting a logon. If the account is disabled because an employee left the company, this event could represent a possible attack.
532	Logon Failure. Expired account.	Check the status of the assigned owner of the account. If this is an account assigned to a temporary worker, is that worker still working? Expiration dates are usually set for temporary workers to ensure that the account is disabled after they have finished their assignment. The expiration date may be an estimate or the worker may have been assigned to a new project. It is typical that IT is not notified of these types of changes, and this could just represent that type of failure. It could also represent an attack.
533	Logon Failure. Account cannot logon at this computer.	Accounts can be restricted to logon at specific computers. If the policy is correctly communicated (letting users know which computers they can use to log on), this event represents an attack or a violation of security policy.
534	Logon Failure. Password type not allowed.	Password type in this instance refers to user rights such as `Access this computer from the network`, `Logon locally`, and so forth used to restrict logon at sensitive computers. If the policy has been communicated correctly (letting users know which computers they can use to logon and which computers they can access), this is an attack, a misconfigured application, or a violation of security policy.
535	Logon Failure. Expired password.	May indicate simple user error or an attack on an account that is rarely used.
539	Logon Failure. Account lockout.	A large number of these events indicates the continuation of a cracking attack.
643	A domain policy was modified.	Be advised of changes to policy.
564	Object deleted.	Compare this event to authorized maintenance that may have required the deletion of a sensitive file.

Configure Auditing for File, Folder, Registry, and Printer Objects

To configure auditing for files, folders, registry, and printer objects, you must configure the Audit object access policy and configure auditing directory on the object. Setting auditing on the object adds an access control entry (ACE) to the object's system access control list (SACL). To configure auditing on files or folders, follow these steps:

Right-click the object and select Properties.

Select the Security tab and click the Advanced button.

Select the Auditing tab.

Click the Add button.

Use the object picker to select the group whose access you want to audit.

Select the permissions to audit, as shown in Figure 18-2, and then click OK.

Figure 18-2. Select specific permissions to audit.

To configure auditing of registry keys, follow these steps:

Right-click the key and select Permissions.

Click the Advanced button.

Select the Auditing tab.

Click the Add button.

Use the object picker to select the group whose access you want to audit.

Select the permissions to audit, as shown in Figure 18-3, and then click OK.

Figure 18-3. Select registry key permissions to audit.

To configure auditing for printers, follow these steps:

Right-click the printer in the Printers and Faxes window and select Properties.

Click the Security tab.

Click the Advanced button.

Select the Auditing tab.

Click the Add button.

Use the object picker to select the group whose access you want to audit.

Select the permissions to audit, as shown in Figure 18-4, and then click OK.

Figure 18-4. Select printer permissions to audit.

If ACEs are set, events are logged to the event log. Like ACEs for DACLs, ACEs for SACLs are composed of a user group or user name and a permission. SACL ACEs are set for success and/or failure, not Allow or Deny. When SACL ACEs are set, any access that meets their conditions will result in a record in the Security Event Log. Which of these objects should you audit? Auditing access to all objects would be of little value. Who cares, for example, if a user is reading documents that they created? A good way to determine what access should be audited is to use the classic approach to data protection: Classify data by its sensitivity and act accordingly. If data is already classified in your organization, you may be able to use this information; if not, using this method requires that you learn from the data owners which data they consider sensitive and to what degree. You can make some educated guess to help you in your discussions with them. For example, you may want to audit access to printers used to print checks, or other printers that have restricted access. Don't forget to apply the same thought process to data that IT owns, such as system files. It's useful, for example, to audit access to the %WINDIR%\system32\config folder on the domain controller. This folder holds the event log files and registry files. Access to the SAM file stored here might mean the DC has been started in restore mode since the SAM is offline on a DC. Access to other files might also bear investigation. By default, only the Administrators group and the system have access to these files, so auditing for permission changes would be wise.

Configure Auditing of AD Objects

Configuring auditing of AD objects is similar to configuring auditing for files and folders permissions. Like other object access, a policy in audit policy as well as specific object settings must be in effect. Some AD objects already have SACL ACEs set. When you configure the Audit Directory Service Access audit policy and these objects are access, audit records will be recorded in the Security Event Log. Just as a limited number of permissions on objects other than directory objects makes setting access controls on these objects easier, the large number of permissions on directory objects makes them difficult to audit. To get started, examine the settings that are preconfigured, and do not make changes or add auditing to additional objects until you have done so.

Until you understand the current settings, you cannot decide if they should be reduced or increased. You must determine the information that they will produce in the security event log and understand why that information would be valuable. To do so, consider the following:

Which objects are preconfigured for audit? What information is sought?

Which groups are audited?

What permissions are audited?

To get started, look at important objects. Start with the obvious. For example, examine the auditing settings for the domain object. You can do so by examining the Auditing Properties page, as displayed in Figure 18-5, of the object. To examine the settings, right-click the domain object in Active Directory Users and Computers and select Properties, then select the Security tab, and use the Advanced button to get to the Auditing page.

Figure 18-5. Audit settings on the domain object are preset to record access.

[View full size image]

Note that access by Everyone, Administrators, and Domain Users is recorded. Note, too, that these auditing settings are not inherited. Auditing settings can be inherited, just like permissions. Also note that the permission sets for each group are not set to record every type of access but are restricted. Finally, note that some settings are only applied to the domain object, while others are more narrowly defined.

Select a group and click the Edit button to examine the specific audit settings. The Special settings for the group Everyone are displayed in Figure 18-6. (Two other Everyone entries in the table must also be looked at to catalog the audit settings for the group Everyone.) Table 18-4 lists the settings for each group.

Table 18-4. Audit Settings on the Domain Object
Group	Access	Apply Onto	Access Task	Type
Everyone	Special	This object only	Write all proper ties, Modify Permissions, Modify Owner	Success
Everyone	Write Property	Special	Write gPLink	Success
Everyone	Write Property	Special	Write gPOptions	Success
Administrators	All Extended Rights	This object only	All Extended Rights (therefore, all extended rights for this object are also checked)	Success
Domain Users	All Extended Rights	This object only	All Extended Rights (therefore, all extended rights for this object are also checked)	Success

Figure 18-6. Review the specifics of auditing settings for each group.

GPLink is a property that holds the list of linked GPOs and includes information on the GPO's Enforced (No Override) and Disabled options. The other write property audit, gPOptions, contains the Block Policy Inheritance options. Auditing additions and changes to GPLink (Write Property) and gPOptions provides information of changes to Group Policy. It's easy to see how valuable this knowledge can be. You can check any recorded changes and determine if they are the result of authorized changes by authorized individual or possible attacks. By default, only a successful change is recorded. In sensitive environments, consider also auditing for failed attempts.

Extended Rights and the rights themselves can be viewed from the Object page of the Auditing entry. In addition to those rights exposed in the GUI, additional rights on the domain object exist, such as Change Password (the user can change their password) and User Force Change Password (some can reset the password). The use of these extended rights is also audited. For the domain object, only some objects are displayed by default. Figure 18-7 displays most of these, and Table 18-5 describes them. For a more comprehensive listing, see a listing of Active Directory Schema Extended Rights in the Platform SDK (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/r_ds_replication_get_changes.asp).

Table 18-5. Extended Rights Audit Settings on the Domain Object
Extended Rights for the Domain Object	Description
`Add GUID`	Add an object with a specific GUID, such as a domain controller, GPO.
`Add Replica in Domain`	Add a new DC to the domain.
`Change PDC`	Transfer or seize the PDC emulator operations master.
`Create Inbound Forest Trust`	Create a trust that provides access to domain objects from another forest.
`Enable Per User Reversibly Encrypted Password`	Enable or disable the reversible encrypted password setting. (Enabling this option drops protection on passwords.)
`Generate Resultant Set of Policy (Logging)`	RSoP logging performed.
`Generate Resultant Set of Policy (Planning)`	RSoP planning performed.
`Manage Replication Topology`	Make changes to replication, replication links.
`Migrate SID History`	This permission can be used to migrate SID HistoryPermissions from another domain are retained by migrated users to this domain. Can be granted to non-administrative users.
`Monitor Active Directory Replication`	Allows replication data, such as replication status and metadata. Replication activity is being monitored.
`Reanimate Tombstones`	A deleted object is recovered.
`Replicate Directory Changes`	Replication has occurred.
`Replicating Directory Changes All`	Replication of all domain data.
`Replication Synchronization`	Ability to synchronize replication.
`Unexpire Password`	Restore a password for a user object.
`Update Password Not Required Bit`	Enable or disable the "password not required" setting for user objects.

Figure 18-7. Extended Rights are defined per object and listed on the Object page.

To successfully use the information generated by Active Directory object auditing, become familiar with the events generated during normal usage. AD object auditing events always are identified as Event ID 566 but provide information on the object, the type of access, and the user name. For example, linking a GPO to the domain container produces several events that document access to gPLink, writing a display name to the Group Policy container, gPCFileSysPath (true or false information about indexing, GC location, and other parameters), version number, and gPCFunctionalityVersion (the version of the Group Policy Editor that produced the write). Figure 18-8 displays one of these events.

Figure 18-8. AD object access events indicate the access and user as well as DC.

Configure Event Log Policy

There are three Windows Server 2003 default logs: System, Application, and Security. Other logs are created depending on the computer role. For example, Windows Server 2003 DNS servers have a DNS event log, while domain controllers have a Directory Service event log and a File Replication Service event log. All logs can be viewed from the Event Viewer, as shown in Figure 18-9. The properties of the event logs can be displayed by right-clicking the log and selecting Properties, as shown in Figure 18-10. Event log properties may be set in Group Policy for the three default logs, as shown in Figure 18-11. Therefore, consistency across servers for these logs is possible. Properties for all other logs must be set directly on the log. Setting properties for these logs requires manual work or a custom script.

Figure 18-9. Events are viewed in the Event Viewer.

[View full size image]

Figure 18-10. Event log properties can be configured directly on the event log.

Figure 18-11. Event log properties for the three default logs can be set in Group Policy.

[View full size image]

Set log properties according to the amount of auditing configured, the level of activity, and the frequency of archive. Table 18-6 lists and describes event log settings and provides some recommendations.

Table 18-6. Event Log Properties
Setting	Description	Recommendation
Maximum log size	Event logs, unlike normal files, do not grow infinitely bounded only by disk space. Instead, they can only grow as large as the size specified here.	Event logs in Windows Server 2003 are set by default to a reasonable size for a newly initialized server. Adjust this size to accommodate the activity depending on server role and to meet the needs of your audit policy. Your audit policy includes an archival period and a policy for what to do if the security event log becomes full. Plan on monitoring log size. A larger log can mean less frequent archival, while smaller logs may have to be archived more frequently.
Retention Method (In individual log properties titled as "When Maximum log size is reached")	Choices are Overwrite events as needed Overwrite events older than x days (also known as "Retain" x days) Do not overwrite events (clear log manually)	Set to "overwrite events as needed." In this case, if the event log is large enough and is archived frequently, no events will be lost. In times of heavy event logging or slow administrator response, only the older events will be lost.
Prevent local Guests group from accessing application log	The Guests group cannot access the log. By default, only administrators and the system can access the Windows Server 2003 event logs	Enable
Prevent local Guests group from accessing security log	The Guests group cannot access the log. By default, only administrators and the system can access the Windows Server 2003 event logs.	Enable
Prevent local Guests group from accessing system log	The Guests group cannot access the log. By default, only administrators and the system can access the Windows Server 2003 event logs.	Enable

Configure User Rights

Two user rights are directly related to the auditing function:

Generate security audits
Accounts with this right can be used to add events to the security log. By default, the Local Service and Network Service accounts are included in the Default Domain Controllers Policy. This user right might be added to a service account to enable its application to add events to the security log. Best practices state that the application should be written, where possible, to use the Local Service or Network Service account for this purpose.

Manage auditing and security log
By default, only the Administrators group has the right to modify the audit policy and manage the security event log. Create a custom Windows group for auditors and provide that group this right. This allows auditors to review the security log without having full administrator rights. Consider the implications of giving them the right to manage the log. This allows auditors, who are often defined as "observers," the ability to change the systems they are auditing.

Chapter 3 of "Introduction to the Working with Active Directory Permissions in Exchange Server 2003 Guide" at http://www.microsoft.com/technet/prodtechnol/Exchange/guides/E2k3ADPerm/52821d76-9941-4eb2-8384-ca4fe790e38e.mspx.

Configure Security Options

In addition to a formal audit policy, several Security Options can be set that affect auditing. The security options are as follows:

Audit: Audit the access of global system objects
Global system objects are objects such as mutexes (used for thread synchronization), events, semaphores (locking objects), and DOS devices. If this policy is enabled, these objects are created with a default SACL, and access to them is audited. By default, this option is not enabled.

Audit: Audit the use of Backup and Restore privilege
Setting this option generates a large number of events during any backup and restore. The backup of each file is recorded. Modern backup programs create logs that can provide this information in a more manageable format.

Audit: Shut down system immediately if unable to log security
If the Retention method in the security event log is Do not overwrite events (Clear log manually) and this Security Option is set, processing on the computer will be stopped if the security log is full. An administrator will have to archive and clear the log, then reset this option before users are able to log on. A stop error C0000244{Audit failed} is generated. Do not set this Security Option unless ensuring a complete log (no events lost) is more important than production and unless an administrator is available at all times to recover from a full log.

Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Establishing a Windows Server 2003 Audit Policy for the Forest

Audit Policy Basics

Figure 18-1. The default Audit Policy for the domain controller's OU.

Determining Which Computers to Audit and Which Events to Collect

Determine and Configure Audit Policy

Table 18-1. Audit Policies

Table 18-2. Audit Policy Recommendations

Interpreting Audit Policy Events

Table 18-3. Suspicious Account Events

Configure Auditing for File, Folder, Registry, and Printer Objects

Figure 18-2. Select specific permissions to audit.

Figure 18-3. Select registry key permissions to audit.

Figure 18-4. Select printer permissions to audit.

Configure Auditing of AD Objects

Figure 18-5. Audit settings on the domain object are preset to record access.

Table 18-4. Audit Settings on the Domain Object

Figure 18-6. Review the specifics of auditing settings for each group.

Table 18-5. Extended Rights Audit Settings on the Domain Object

Figure 18-7. Extended Rights are defined per object and listed on the Object page.

Figure 18-8. AD object access events indicate the access and user as well as DC.

Configure Event Log Policy

Figure 18-9. Events are viewed in the Event Viewer.

Figure 18-10. Event log properties can be configured directly on the event log.

Figure 18-11. Event log properties for the three default logs can be set in Group Policy.

Table 18-6. Event Log Properties

Configure User Rights

Configure Security Options