|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
NavigationMy posts on Twitter
|
Audit Policy Settings for Windows XPAn Audit policy determines the security events to report to administrators so that user or system activity in specified event categories is recorded. The administrator can monitor security-related activity, such as who accesses an object, when users log on to or log off from computers, or if changes are made to an Audit policy setting. For all of these reasons, Microsoft recommends that you form an Audit policy for an administrator to implement in your environment. However, before you implement an Audit policy you must decide which event categories need to be audited in your environment. The audit settings you choose within the event categories define your Audit policy. When you define audit settings for specific event categories, an administrator can create an Audit policy that will meet the security needs of your organization. If no audit settings are configured, it will be difficult or impossible to determine what took place during a security incident. However, if audit settings are configured so that too many authorized activities generate events, the Security event log will fill up with useless data. The information in the following sections is designed to help you decide what to monitor and how to collect relevant audit data for your organization. You can configure the Audit policy settings in Windows XP at the following location in the Group Policy Object Editor: Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy
The following table summarizes the Audit policy setting recommendations for both desktop and laptop client computers in the two types of secure environments that are discussed in this chapter. The Enterprise Client environment is referred to as EC, and the Specialized Security – Limited Functionality environment is referred to as SSLF. You should review these recommendations and adjust them as appropriate for your organization. However, be very cautious about audit settings that can generate a large volume of traffic. For example, if you enable either success or failure auditing for Audit privilege use, so many audit events will be generated that it may not be feasible to find other types of entries in the Security event log. Such a configuration could also have a significant impact on performance. More detailed information about each of the settings is provided in the following subsections.
Audit account logon eventsIf this policy setting is enabled, events for credential validation are generated. These events occur on the computer that is authoritative for the credentials. For domain accounts the domain controller is authoritative, and for local accounts the local computer is authoritative. In domain environments, most of the Account Logon events occur in the Security log of the domain controllers that are authoritative for the domain accounts. However, these events can occur on other computers in the organization depending on the accounts that are used to log on. In this guidance, the Audit account logon events setting is configured to Success only for the EC environment and to Success and Failure for the SSLF environment. Audit account managementThis policy setting is used to track attempts to create new users or groups, rename users or groups, enable or disable user accounts, change account passwords, and enable auditing for Account Management events. If you enable this Audit policy setting, administrators can track events to detect malicious, accidental, and authorized creation of user and group accounts. The Audit account management setting is configured to Success for the EC environment and to Success and Failure for the SSLF environment. Audit directory service accessThis policy setting can only be enabled to perform audit tasks on domain controllers. For this reason, the setting is not defined at the workstation level. This policy setting does not apply to computers that run Windows XP Professional. Therefore, ensure that the Audit directory service access setting is configured to Not Defined for the two environments that are discussed in this chapter. Audit logon eventsThis policy setting generates events that record the creation and destruction of logon sessions. These events occur on the computer that is accessed. For interactive logons, these events would be generated on the computer that was logged on to. If a network logon was performed to access a share, these events would be generated on the computer that hosts the resource that was accessed. If you configure the Audit logon events setting to No auditing, it is difficult or impossible to determine which user has either accessed or attempted to access computers in the organization. The Audit logon events setting is configured to log Success events for the EC environment. This policy setting is configured to Success and Failure events for the SSLF environment. Audit object accessBy itself, this policy setting will not cause any events to be audited. It determines whether to audit the event of a user who accesses an object - for example, a file, folder, registry key, or printer - that has a specified system access control list (SACL). A SACL is comprised of access control entries (ACEs). Each ACE contains three pieces of information:
If you configure the Audit object access setting to Success, an audit entry is generated each time that a user successfully accesses an object with a specified SACL. If you configure this policy setting to Failure, an audit entry is generated each time that a user unsuccessfully attempts to access an object with a specified SACL. Organizations should define only the actions they want enabled when they configure SACLs. For example, you might want to enable the Write and Append Data auditing setting on executable files to track when they are changed or replaced, because computer viruses, worms, and Trojan horses typically target executable files. Similarly, you might want to track when sensitive documents are accessed or changed. The Audit object access setting is configured to No Auditing for the EC environment and to Failure for the SSLF environment. You must enable this setting for the following procedures to take effect. The following procedures detail how to manually set up audit rules on a file or folder and how to test each audit rule for each object in the specified file or folder. The testing procedure may be automated by means of a script file. To define an audit rule for a file or folder
To test an audit rule for the file or folder
Audit policy changeThis policy setting determines whether to audit every incident of a change to user rights assignment policies, Windows Firewall policies, Trust policies, or changes to the Audit policy itself. The recommended settings would let you see any account privileges that an attacker attempts to elevate - for example, by adding the Debug programs privilege or the Back up files and directories privilege. The Audit policy change setting is configured to Success for the two environments that are discussed in this chapter. The setting value for Failure is not included because it will not provide meaningful access information in the Security event log. Audit privilege useThis policy setting determines whether to audit each instance of a user exercising a user right. If you configure this value to Success, an audit entry is generated each time that a user right is exercised successfully. If you configure this value to Failure, an audit entry is generated each time that a user right is exercised unsuccessfully. This policy setting can generate a very large number of event records. The Audit privilege use setting is configured to No Auditing for computers in the EC environment and to Failure for the SSLF environment to audit all unsuccessful attempts to use privileges. Audit process trackingThis policy setting determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access. Enabling Audit process tracking will generate a large number of events, so typically it is set to No Auditing. However, this setting can provide a great benefit during an incident response from the detailed log of the processes started and the time when they were launched. The Audit process tracking setting is configured to No Auditing for the two environments that are discussed in this chapter. Audit system eventsThis policy setting is very important because it allows you to monitor system events that succeed and fail, and provides a record of these events that may help determine instances of unauthorized system access. System events include starting or shutting down computers in your environment, full event logs, or other security-related events that affect the entire system. The Audit system events setting is configured to Success for both of the environments that are discussed in this chapter. |
|
||||||||||||||||||||||||||||||||||||||||||||||||||
| © Copyleft 2005-2011 - Lode Vanstechelman - Login | ||||||||||||||||||||||||||||||||||||||||||||||||||||