Threats and Countermeasures
Chapter 3: Audit Policy
An audit log records an entry whenever users perform certain specified actions. For example, the modification of a file or a policy can trigger an audit entry that shows the action that was performed, the associated user account, and the date and time of the action. You can audit both successful and failed attempts at actions. The state of the operating system and applications on a computer is dynamic. For example, security levels may be temporarily changed to enable immediate resolution of an administration or network issue. However, such changes are often forgotten about and never undone. If security levels are not properly reset, a computer may no longer meet the requirements for enterprise security. Regular security analyses enable administrators to track and determine that adequate security measures are in effect for each computer as part of an enterprise risk management program. Such analyses focus on highly specific information about all aspects of a computer that relate to security, which administrators can use to adjust the security levels. More importantly, this information can help detect any security flaws that may occur in the computer over time. Security audits are extremely important for any enterprise network, because audit logs may provide the only indication that a security breach has occurred. If the breach is discovered some other way, proper audit settings will generate an audit log that contains important information about the breach. Oftentimes, failure logs are much more informative than success logs because failures typically indicate errors. For example, successful logon to a computer by a user would typically be considered normal. However, if someone unsuccessfully tries to log on to a computer multiple times, it may indicate an attacker's attempt to break into the computer with someone else's account credentials. The event logs record events on the computer, and in Microsoft® Windows® operating systems, there are separate event logs for applications, security events, and system events. The Security log records audit events. The event log container of Group Policy is used to define attributes that relate to the Application, Security, and System event logs, such as maximum log size, access rights for each log, and retention settings and methods. This guide includes a Microsoft Excel® workbook, "Windows Default Security and Services Configuration," that documents the default settings. Before any audit processes are implemented, an organization should determine how they will collect, organize, and analyze the data. There is little value in large volumes of audit data if there is no underlying plan to exploit it. Also, audit settings can affect computer performance. The effect of a given combination of settings may be negligible on an end-user computer but quite noticeable on a busy server. Therefore, you should perform some performance tests before you deploy new audit settings in your production environment. You can configure the Audit policy settings in the following location within the Group Policy Object Editor: Computer Configuration\Windows Settings\Security Settings\Local Policies On This Page
Audit SettingsThe vulnerabilities, countermeasures, and potential impacts of all the audit settings are identical. Therefore, these terms are described only once. Each description is then followed by brief explanations of each setting. The options for each of the audit settings are:
Vulnerability If no audit settings are configured, it will be difficult or impossible to determine what occurred during a security incident. However, if audit settings are configured so that too many authorized activities generate events, the Security event log will be filled with useless data. Also, you can affect overall computer performance if you configure audit settings for a large number of objects. Countermeasure You should enable sensible Audit policy settings for all computers in your organization so that users can be held accountable for their actions and unauthorized activity can be detected and tracked. Potential Impact If no audit settings are configured, or if audit settings are too lax on the computers in your organization, not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities. Audit account logon eventsThis policy setting determines whether to audit each instance of user logon or logoff on a different computer than the one that records the event and validates the account. If you configure this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when an account logon attempt succeeds, which is useful information for accounting purposes and for post-incident forensics so that you can determine who successfully logged into which computer. Failure audits generate an audit entry when an account logon attempt fails, which is useful for intrusion detection. However, this policy setting also creates the potential for a denial of service (DoS) attack. When the Audit: Shut down system immediately if unable to log security audits setting is enabled, an attacker could generate millions of logon failures, fill the Security event log, and force the computer to shut down. If you configure the Audit account logon events setting to Success on a domain controller, an entry is logged for each user who is validated against that domain controller, even though the user actually logs on to a workstation or server that is joined to the domain. Audit account managementThis policy setting determines whether to audit each account management event on a computer. Examples of account management events include the following:
If you configure the Audit account management setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when any account management event succeeds, and you should enable them on all computers in your enterprise. When an organization responds to security incidents, it is critical that they be able to track who created, changed, or deleted an account. Failure audits generate an audit entry when any account management event fails. Audit directory service accessThis policy setting determines whether to audit user access of an Active Directory® directory service object that has an associated system access control list (SACL). A SACL is list of users and groups for which actions on an object are to be audited on a Microsoft Windows–based network. If you configure the Audit directory service access setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an Active Directory object that has a SACL that indicates that the user should be audited for the requested action. Failure audits generate an audit entry when a user unsuccessfully attempts to access an Active Directory object that has a SACL that requires auditing. (Both types of audit entries are created before the user is notified that the request succeeded or failed.) If you enable this policy setting and configure SACLs on directory objects, a large volume of entries can be generated in the Security logs on domain controllers. You should only enable these settings if you actually intend to use the information that is created. Note: You can configure a SACL on an Active Directory object through the Security tab in that object's Properties dialog box. This method is analogous to Audit object access, except that it applies only to Active Directory objects and not to file system and registry objects. Audit logon eventsThis policy setting determines whether to audit each instance of user logon, logoff, or network connection to the computer that records the audit event. If you log successful account logon audit events on a domain controller, workstation logon attempts do not generate logon audits. Only interactive and network logon attempts to the domain controller itself generate logon events on the domain controller. To summarize, account logon events are generated where the account lives, and logon events are generated where the logon attempt occurs. If you configure the Audit logon events setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a logon attempt succeeds, which is useful information for accounting purposes and for post-incident forensics so that you can determine who successfully logged on to which computer. Failure audits generate an audit entry when a logon attempt fails, which is useful for intrusion detection. However, this configuration also creates a potential DoS condition, because an attacker could generate millions of logon failures, fill the Security event log, and force the server to shut down. Audit object accessThis policy setting 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 SACL that specifies a requirement for auditing. If you configure the Audit object access setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an object that has a SACL. Failure audits generate an audit entry when a user unsuccessfully attempts to access an object that has a SACL (some failure events are to be expected during normal computer operations). For example, many applications (such as Microsoft Word) always attempt to open files with both read and write privileges. If the applications are unable to do so, they then try to open the files with read-only privileges. If you enable failure auditing and the appropriate SACL on the file, a failure event will be recorded when such an event occurs. In Microsoft Windows Server™ 2003 with Service Pack 1 (SP1), you can audit access to objects that are stored in the Internet Information server (IIS) metabase. To enable metabase object auditing, you must enable Audit object access on the target computer, and then set SACLs on the specific metabase objects whose access you want to audit. If you configure the Audit object access policy setting and configure SACLs on objects, a large volume of entries can be generated in the Security logs on computers in your organization. Therefore, you should only enable these settings if you actually intend to use the information that is logged. Note: You must perform a two-step process to enable the capability to audit an object, such as a file, folder, printer, or registry key, in Windows Server 2003. After you enable the audit object access policy, you must determine the objects whose access you want to monitor, and then modify their SACLs accordingly. For example, if you want to audit any attempts by users to open a particular file, you can configure a Success or Failure audit attribute directly on the file that you want to monitor for that particular event with Windows Explorer or Group Policy. Audit policy changeThis policy setting determines whether to audit every incidence of a change to user rights assignment policies, Windows Firewall policies, Audit policies, or trust policies. If you configure the Audit policy change setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when a change to user rights assignment policies, Audit policies, or trust policies is successful. This audit information is useful for accounting purposes and can help you determine who successfully modified policies in the domain or on individual computers. Failure audits generate an audit entry when a change to user rights assignment policies, Audit policies, or trust policies fails. If you enable the Audit policy change setting in Windows XP with SP2 and Windows Server 2003 with SP1, logging of configuration changes for the Windows Firewall component is also enabled. Audit privilege useThis policy setting determines whether to audit each instance of a user who exercises a user right. If you configure the Audit privilege use setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when the exercise of a user right succeeds. Failure audits generate an audit entry when the exercise of a user right fails. If you enable this policy setting, the volume of events that is generated can be very large and the events may be difficult to sort through. You should only enable this setting if you have a plan for how you will use the information that is generated. Audit events are not generated for use of the following user rights, even if success audits or failure audits are specified for this policy setting:
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. If you configure the Audit process tracking setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when the process being tracked succeeds. Failure audits generate an audit entry when the process being tracked fails. If you enable Audit process tracking in Windows XP with SP2 and Windows Server 2003 with SP1, Windows will also log information about the operating mode and status of the Windows Firewall component. When enabled, the Audit process tracking setting generates a large number of events. This policy setting is typically configured to No Auditing. However, the information that this policy setting generates can be very beneficial during an incident response because it provides a detailed log of the processes that were started and when they were launched. Audit system eventsThis policy setting determines whether to audit when a user restarts or shuts down their computer, or when an event occurs that affects either computer security or the Security log. If you configure the Audit system events setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when an event executes successfully. Failure audits generate an audit entry when an event is unsuccessful. Because few additional events are recorded if both failure and success audits are enabled for system events, and because all such events are very significant, you should configure this policy setting to Enabled on all computers in your organization. Audit Example: Results of a User Logon EventAfter you become familiar with the different audit settings that are available in Windows, it may be helpful to consider a specific example. Audits are performed from an individual computer's perspective, rather than from the more holistic perspective that an enterprise administrator may prefer. Because events are recorded on individual computers, you may need to examine the Security logs of multiple computers and correlate the data to determine what occurred. The rest of this chapter shows the core events that are written to the event logs of a domain controller, a file server, and an end-user computer when an authorized user logs on to their computer and accesses a file on a shared folder that is hosted by the file server. Only the core events are documented—other events that are generated by these activities were omitted for the sake of clarity. The names of the accounts and resources involved in this example are:
User logs on to their computer
User connects to the shared folder called Share
User opens the file document.txt
User saves the file document.txt
Although this example looks like a complex series of events, it has been greatly simplified. The listed actions would actually generate dozens of logon, logoff, and privilege use events on the domain controller and file server. When the user opens the file, scores of object access events are also generated, and each time the user saves the file many more events are generated. As you can see, the use of audit data can be a challenge without the support of automated tools such as Microsoft Operations Manager. More InformationThe following links provide additional information about topics that relate to Audit policies for computers that run Windows XP with SP2 or Windows Server 2003 with SP1:
|
In This Article
|
