Planning and Deploying Advanced Security Audit Policies

Applies To: Windows 7, Windows 8 Release Preview, Windows Server 2008 R2, Windows Server 2012

This document explains the options that security policy planners must consider and the tasks they must complete to deploy an effective security audit policy in a network that includes computers running Windows 7 or Windows Server 2008 R2.

Organizations invest a large portion of their information technology budgets on security applications and services, such as antivirus software, firewalls, and encryption. But no matter how much security hardware or software you deploy, how tightly you control the rights of users, or carefully you configure security permissions on your data, you should not consider the job complete unless you have a well-defined, timely auditing strategy to track the effectiveness of your defenses and identify attempts to circumvent them.

To be well defined and timely, an auditing strategy must provide useful tracking data on an organization's most important resources, critical behaviors, and potential risks. In a growing number of organizations, it must also provide absolute proof that IT operations comply with corporate and regulatory requirements.

Unfortunately, no organization has unlimited resources to monitor every single resource and activity on a network. If you do not plan well enough, you will likely have gaps in your auditing strategy. However, if you try to audit every resource and activity, you may find yourself with far too much monitoring data, including thousands of benign audit entries that an analyst would need to sift through to identify the narrow set of entries that warrant closer examination. This could cause delays or even prevent auditors from identifying suspicious activity. Thus, over-monitoring can leave an organization as vulnerable as monitoring too little.

New auditing features in Windows 7 and Windows Server 2008 R2 make it easier to audit important user, computer, and network activities in a focused, efficient manner. These features include:

• Advanced audit policy settings, which allow administrators to apply and manage detailed audit policy settings in a much more narrowly defined manner than previously through their existing Group Policy framework.

• "Reason for access" auditing, which enables administrators to specify and identify the permissions that were used to generate a particular object access security event.

• Global object access auditing, which allows administrators to define system access control lists (SACLs) for an entire computer file system or registry.

To deploy these features and plan an effective security auditing strategy, you need to identify your most critical resources and the most important activities that need to be tracked, identify the audit settings that can be used to track these activities, assess the advantages and potential costs associated with each, test these settings to validate your choices, and develop plans for deploying and managing your audit policy.

About this guide

This document will guide you through the steps needed to plan a security auditing policy that uses Windows auditing features. This policy must identify and address vital business needs, including:

• Network reliability

• Regulatory requirements

• Protection of the organization's data and intellectual property

• Users, including employees, contractors, partners, and customers

• Client computers and applications

• Servers and the applications and services running on those servers

The audit policy also must identify processes for managing audit data after it has been logged, including:

• Collecting, evaluating, and reviewing audit data

• Storing and, if required, disposing of audit data

By carefully planning, designing, testing, and deploying a solution based on your organization's business requirements, you can provide the standardized functionality, security, and management control that your organization needs.

Terminology used in this guide

Understanding the following terms will help you apply the guidance in this document:

• Group Policy. The Windows feature that allows administrators to specify options for managed configurations for groups of computers and users.

• Audit policy. The nine security audit policy settings under Security Settings\Local Policies\Audit Policy and 53 audit policy settings under Security Settings\Advanced Audit Policy Configuration that determine the security events to be recorded in the security event log.

• Success audit. An audit event that is triggered when a defined action, such as accessing a file share, is completed successfully.

• Failure audit. An audit event that is triggered when a defined action, such as a user logon, is not completed successfully.

• System access control lists (SACLs). A section of the security descriptor for objects that is used to maintain per-object auditing information. For many types of objects, such as file system objects or registry settings, audit events are logged only if the relevant audit policy has been applied to the computer and a corresponding SACL has been configured on the object. However, you can ensure that a system-wide SACL is applied to all file system objects or all registry settings on a computer by using global object access auditing.

• "Reason for access" audit. This list of access control entries (ACEs) provides the privileges on which the decision to allow or deny access to the object was based. This can be useful for documenting the permissions, such as group memberships, that allow or prevent the occurrence of a particular auditable event. For more information about using "reason for access" auditing, see the Advanced Security Audit Policy Step-by-Step Guide.

• Global object access auditing. In Windows Server 2008 R2 and Windows 7, a computer-wide SACL can be applied to all objects in the file system or to all registry settings. The specified SACL is automatically applied to every single object of that type, overriding any other SACLS configured for or applied to that object. For more information about using global object access auditing, see the Advanced Security Audit Policy Step-by-Step Guide.

Understanding the security audit policy design process

The process of designing and deploying a Windows security audit policy involves the following tasks, which are described in greater detail throughout this document:

• Identifying your Windows security audit policy deployment goals

  This section will help you define the business objectives that will guide your Windows security audit policy. It will also help you define the resources, users, and computers to be the focus of your security auditing.

• Mapping the security audit policy to groups of users, computers, and resources in your organization

  This section explains how to integrate security audit policy settings with domain Group Policy for different groups of users, computers, and resources. In addition, if your network includes multiple versions of Windows client and server operating systems, it will also explain when to use basic audit policy settings and when to use advanced security audit policy settings.

• Mapping your security auditing goals to a security audit policy configuration

  This section will explain the different categories of Windows security auditing settings that are available. It will also identify individual Windows security auditing policy settings that can be of particular value to address different auditing scenarios.

• Planning for security audit monitoring and management

  This section will help you plan for collecting, analyzing, and storing Windows audit data. Depending on the number of computers and types of activity you want to audit, Windows event logs can fill up quickly. In addition, you need to determine how auditors will access and aggregate event data from multiple servers and desktop computers. You also have to address storage requirements, including how much audit data to store and how it must be stored.

• Deploying the security audit policy

  This section provides recommendations and guidelines for the effective deployment of a Windows security audit policy. Configuring and deploying Windows audit policy settings in a test lab environment can help you confirm that the settings you have selected will produce the type of audit data you need. However, only a carefully staged pilot and incremental deployments based on your domain and organizational unit (OU) structure will enable you to confirm that the audit data you generate can be monitored and meets your organization's audit needs.

Identifying your Windows security audit policy deployment goals

Security audit policy must support and be a critical and integrated aspect of an organization's overall security design and framework. The following resources can help you create and implement an overall Windows security framework for your organization:

• Windows Server 2008 Security Guide (https://go.microsoft.com/fwlink/?LinkID=105788)

• Windows Vista Security Guide (https://go.microsoft.com/fwlink/?LinkId=163431)

Every organization has a unique set of data and network assets (such as customer and financial data and trade secrets), physical resources (such as desktop computers, portable computers, and servers), and users (which can include various internal groups such as finance and marketing, and external groups such as partners, customers, and anonymous users on the Web). Not all of these assets, resources, and users will justify the cost of being audited. Your task is to identify which assets, resources, and users provide the strongest justification for being the focus of security auditing.

To create your Windows security audit plan, begin by identifying:

• The overall network environment, including the domains, OUs, and security groups.

• The resources on the network, the users of those resources, and how those resources are being used.

• Regulatory requirements.

Network environment

An organization's domain and OU structure provide a fundamental starting point for thinking about how to apply security audit policy because it likely provides a foundation of Group Policy objects (GPOs) and logical grouping of resources and activities that you can use to apply the audit settings that you choose. It is also likely that certain portions of your domain and OU structure already provide logical groups of users, resources, and activities that justify the time and resources needed to audit them. For information about how to integrate a security audit policy with your domain and OU structure, see Mapping the security audit policy to groups of users, computers, and resources in your organization later in this document.

In addition to your domain model, you should also find out whether your organization creates and maintains a systematic threat model. A good threat model can help you identify threats to key components in your infrastructure, so you can define and apply audit settings that enhance the organization's ability to identify and counter those threats.

For additional details on how to complete each of these steps and how to prepare a detailed threat model, download the Solution Accelerators IT Infrastructure Threat Modeling Guide (https://go.microsoft.com/fwlink/?LinkId=163432).

Data and resources

For data and resource auditing, you need to identify the most important types of data and resources—such as patient records, accounting data, or marketing plans—that can benefit from the closer monitoring that Windows auditing can provide. Some of these data resources might already be monitored through auditing features in products such as Microsoft SQL Server and Exchange Server. If so, you may want to consider how Windows auditing features can enhance the existing audit strategy. As with the domain and OU structure discussed previously, security auditing should focus on your most critical resources. You also must consider how much audit data you will be able to manage.

You can record whether these resources have high business impact, medium business impact, or low business impact, the costs to the organization if these data resources are accessed by unauthorized users, and the risk that this access can pose to the organization. The type of access, such as Read, Modify, or Copy, can also pose different levels of risk to an organization.

Increasingly, data access and use is governed by regulations, and a breach can result in severe penalties and a loss in credibility for the organization. If regulatory compliance plays a role in how you manage your data, be sure to document this information as well.

The following table is an example of a resource analysis for an organization.

Users

Many organizations find it useful to classify the types of users they have and base permissions on this classification. This same classification can help you identify which user activities should be the subject of security auditing and the amount of audit data they will generate.

Organizations can create distinctions based on the type of rights and privileges needed by users to perform their jobs. For example, under the classification Administrators, larger organizations might assign local administrator responsibilities for a single computer, for specific applications such as Exchange Server or SQL Server, or for an entire domain. Under Users, permissions and Group Policy settings can apply to as many as all users in an organization or as few as a subset of the employees in a given department.

Also, if your organization is subject to regulatory requirements, user activities such as accessing medical records or financial data may need to be audited to verify that you are complying with these requirements.

To effectively audit user activity, begin by listing the different types of users in your organization and the types of data they need access to—in addition to the data they should not have access to.

Also, if external users can access any of your organization's data, be sure to identify them, including whether they belong to a business partner, customer, or general user, the data they have access to, and the permissions they have on that data.

The following table illustrates an analysis of users on a network. Although our example contains a single column titled "Possible auditing considerations," you may want to create additional columns to differentiate between different types of network activity, such as logon hours and permission use.

Computers

Security and auditing requirements and audit event volume can vary considerably for different types of computers in an organization. These requirements can be based on whether:

• The computers are servers, desktop computers, or portable computers.

• The important applications they run, such as Exchange Server, SQL Server, and Forefront Identity Manager.

• The operating system versions that they run.

• The business value of the data they contain.

For example, a Web server that is accessed by external users would require different audit settings than a root certification authority (CA) that is never exposed to the public Internet or even to regular users on the organization's network.

The following table illustrates an analysis of computers in an organization.

Regulatory requirements

Many industries and locales have strict and specific requirements for network operations and how resources are protected. In the health care and financial industries, for example, there are strict guidelines for who has access to records and how they are used. Many countries have strict privacy rules. Work with your organization's legal department and others to identify these regulatory requirements. Then consider the security configuration and auditing options that can be used to comply with and verify compliance with these regulations.

For more information, see the IT Compliance Management Guide (https://go.microsoft.com/fwlink/?LinkId=163435).

Mapping the security audit policy to groups of users, computers, and resources in your organization

By using Group Policy, you can apply your security audit policy to defined groups of users, computers, and resources. To map security auditing policy to these defined groups in your organization, you should understand the following considerations for using Group Policy to apply audit policy settings:

• The audit policy settings you identify can be applied using one or more GPOs. To create and edit a GPO, use the Group Policy Management Console (GPMC). By using the GPMC to link a GPO to selected Active Directory sites, domains, and OUs, you apply the policy settings in the GPO to the users and computers in those Active Directory objects. An OU is the lowest-level Active Directory container to which you can assign Group Policy settings.

• For every policy setting that you select, you need to decide whether it should be enforced across the organization, or whether it should only apply to selected users or computers. You can then combine these audit policy settings into GPOs and link them to the appropriate Active Directory containers.

• By default, options set in GPOs linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, inherited policy can be overridden by a GPO that is linked at a lower level.

  For example, you might use a domain GPO to assign an organization-wide group of audit settings but want a certain OU to get a defined group of additional settings. To accomplish this, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy loopback processing).

• Audit policies are computer policies and therefore must be applied through GPOs applied to computer OUs, not user OUs. However, in most cases where you want audit settings to apply only to specified resources and groups of users, you can accomplish this by configuring SACLs on the relevant objects to enable auditing for a security group that contains only the users you specify. For example, you can configure a SACL on a folder called Payroll Data to enable auditing on attempts by members of the Payroll Processors OU to delete objects from this folder on Accounting Server 1. The Object Access\Audit File System audit policy setting applies to all of Accounting Server 1, but because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.

• As described previously, advanced security audit policy settings can be applied to computers running Windows Server 2008 R2 or Windows 7 only by using Group Policy. These settings can also be applied to computers running Windows Vista or Windows Server 2008, but with these operating systems you must use logon scripts to apply advanced audit policy. Therefore, consider upgrading computers in high-security OUs first so that you can use Group Policy to apply and manage advanced audit policy to monitor these high-value computers and their users.

For more information, see [article 921469](https://go.microsoft.com/fwlink/?linkid=82447) in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=82447).  
  

The following are examples of how audit policy can be applied to an organization's OU structure:

• Apply data activity settings to an OU containing file servers. If your organization has servers containing particularly sensitive data, consider putting them in a separate OU so that you can configure and apply a more precise audit policy to these servers.

• Apply user activity audit policy to an OU containing all computers in the organization. If your organization places users in OUs based on the department they work in, consider configuring and applying more detailed security permissions on critical resources accessed by employees who work in more sensitive areas, such as network administrators or the Legal department.

• Apply network and system activity audit policy to OUs containing the organization's most critical servers, such as domain controllers, CAs, e-mail servers, or database servers.

For more information about planning and deploying Group Policy, see the Group Policy Planning and Deployment Guide.

Mapping your security auditing goals to a security audit policy configuration

After you identify your security auditing goals, you can begin to map them to a security audit policy configuration. This audit policy configuration must address your most critical security auditing goals, but it also must address your organization's constraints, such as the number of computers that need to be monitored, the number of activities that you want to audit, the number of audit events that your desired audit configuration will generate, and the number of administrators available to analyze and act upon audit data.

To create your audit policy configuration, you need to:

1. Explore all of the audit policy settings that can be used to address your needs.

2. Choose the audit settings to use that will most effectively address the audit requirements identified in the previous section.

3. Confirm that the settings you choose are compatible with the operating systems running on the computers that you want to monitor.

4. For the audit settings that you are interested in, decide which configuration options (Success, Failure, or both Success and Failure) you want to use.

5. Deploy the audit settings in a lab or test environment to verify that they meet your desired results, in terms of volume, supportability, and comprehensiveness. Then, deploy the audit settings in a pilot production environment to ensure that your estimates of how much audit data your audit plan will generate are realistic and that you can manage this data.

Exploring audit policy options

Security audit policy settings in Windows Server 2008 R2 and Windows 7 can be viewed and configured in the following locations:

• Security Settings\Local Policies\Audit Policy. For more information, see Audit Policy Settings Under Local Policies\Audit Policy.

• Security Settings\Local Policies\Security Options. For more information, see Audit Policy Settings Under Local Policies\Security Options.

• Security Settings\Advanced Audit Policy Configuration. For more information, see Advanced Security Audit Policy Settings.

Choosing audit settings to use

Depending on your goals, different sets of audit settings may be of particular value to you. To simplify the selection process, we have highlighted some settings under Security Settings\Advanced Audit Policy Configuration that can be used to monitor the following types of activity:

• Data and resources

• Users

• Network

Data and resource activity

For many organizations, compromising the organization's data resources can cause tremendous financial losses, in addition to lost prestige and legal liability. If your organization has critical data resources that need to be protected against any breach, the following settings can provide extremely valuable monitoring and forensic data:

• Object Access\Audit File Share. This policy setting allows you to track what content was accessed, the source (IP address and port) of the request, and the user account used for the access. The volume of event data generated by this setting will vary depending on the number of client computers who attempt to access the file share. On a file server or domain controller, volume may be high (due to SYSVOL access by client computers for policy processing). If you do not need to record routine access by client computers who have permissions on the share, you may want to log audit events only for failed attempts to access the share.

• Object Access\Audit File System. This policy setting determines whether the operating system audits user attempts to access file system objects. Audit events are only generated for objects (such as files and folders) that have configured SACLs, and only if the type of access requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL. (For more information, see Apply or Modify Auditing Policy Settings for a Local File or Folder. If success auditing is enabled, an audit entry is generated each time any account successfully accesses a file system object that has a matching SACL. If failure auditing is enabled, an audit entry is generated each time any user unsuccessfully attempts to access a file system object that has a matching SACL. The amount of audit data generated by the Audit File System policy setting can vary considerably, depending on the number of objects that have been configured to be monitored.

• Object Access\Audit Handle Manipulation. This policy setting determines whether the operating system generates audit events when a handle to an object is opened or closed. Only objects with configured SACLs generate these events, and only if the attempted handle operation matches the SACL. Event volume can be high, depending on how SACLs are configured. When used together with the Audit File System or Audit Registry policy settings, the Audit Handle Manipulation policy setting can provide an administrator with useful "reason for access," audit data detailing the precise permissions on which the audit event is based. For example, if a file is configured as a read-only resource but a user attempts to save changes to the file, the audit event will log not just the event itself but the permissions that were used, or attempted to be used, to save the file changes.

• Global Object Access Auditing. A growing number of organizations are using security auditing to comply with regulatory requirements governing data security and privacy. But demonstrating that strict controls are being enforced can be extremely difficult. To address this problem, Windows Server 2008 R2 and Windows 7 include two Global Object Access Auditing policy settings, one for the registry and one for the file system, which apply a global system access control SACL that cannot be overridden or circumvented on all objects of that class on a system.

User activity

Where the settings in the previous section relate to activity involving the files, folders, and network shares that are stored on a network, the following settings focus on the users, including employees, partners, and customers, who may try to access those resources. In the majority of cases, those attempts will be legitimate and a network needs to make vital data readily available to legitimate users. In other cases, however, employees, partners, and others may attempt to access resources that they have no legitimate reason to access. Security auditing can be used to track a wide variety of user activities on a particular computer to diagnose and resolve problems for legitimate users and identify and address illegitimate activities. The following are a few important settings that you should evaluate to track user activity on your network:

• Account Logon\Audit Credential Validation. This is an extremely important policy setting because it enables you to track every successful and unsuccessful attempt to present credentials for a user logon. In particular, a pattern of unsuccessful attempts may indicate that a user or application is using credentials that are no longer valid, or attempting to use a variety of credentials in succession in hope that one of these attempts will eventually be successful. These events occur on the computer that is authoritative for the credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative.

• Detailed Tracking\Audit Process Creation and Detailed Tracking\Audit Process Termination. The Audit Process Creation and Audit Process Termination policy settings can enable you to monitor the applications that a user opens and closes on a computer.

• DS Access\Audit Directory Service Access and DS Access\Audit Directory Service Changes. Audit Directory Service Access and Audit Directory Service Changes policy settings provide a detailed audit trail of attempts to access create, modify, delete, move, or undelete objects in Active Directory Domain Services (AD DS). Only domain administrators have permission to modify AD DS objects, so it is extremely important to identify malicious attempts to modify these objects. In addition, although domain administrators should be among an organization's most trusted employees, the use of Audit Directory Service Access and Audit Directory Service Changes settings allow you to monitor and verify that only approved changes are made to AD DS. These audit events are logged only on domain controllers.

• Logon/Logoff\Audit Account Lockout. Another common security scenario occurs when a user attempts to log on with an account that has been locked out. It is important to identify these events and to determine whether the attempt to use an account that has been locked out is malicious or not.

• Logon/Logoff\Audit Logoff and Logon/Logoff\Audit Logon. Logon and logoff events are essential to tracking user activity and detecting potential attacks. Logon events are related to the creation of logon sessions and occur on the computer that was accessed. For an interactive logon, events are generated on the computer that was logged on to. For network logon, such as accessing a share, events are generated on the computer hosting the resource that was accessed. Logoff events are generated when logon sessions are terminated.

• Logon/Logoff\Audit Special Logon. A special logon is a logon that has administrator-equivalent privileges and can be used to elevate a process to a higher level. It is recommended to track these types of logons. For more information about this feature, see article 947223 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=120183).

• Object Access\Audit Certification Services. The Audit Certification Services policy setting allows you to track and monitor a wide variety of activities on a computer hosting Active Directory Certificate Services (AD CS) role services to ensure that only authorized users are performing or attempting to perform these tasks, and that only authorized or desired tasks are being performed.

• Object Access\Audit File System and Object Access\Audit File Share. The Audit File System and Audit File Share policy settings are described in the previous section.

• Object Access\Audit Handle Manipulation. The Audit Handle Manipulation policy setting and its role in providing "reason for access" audit data is described in the previous section.

• Object Access\Audit Registry. Monitoring for changes to the registry is one of the most critical means an administrator has to ensure that malicious users do not make changes to essential computer settings. Audit events are only generated for objects that have configured SACLs specified, and only if the type of access requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL.

• Object Access\Audit SAM. The Security Accounts Manager (SAM) is a database present on computers running Windows that stores user accounts and security descriptors for users on the local computer. Changes to user and group objects are tracked by the Account Management audit category. However, user accounts with enough privileges could potentially alter the files where the account and password information is stored in the system, bypassing any Account Management events.

• Privilege Use\Audit Sensitive Privilege Use. Privilege Use policy settings and audit events allow you to track the use of certain privileges on one or more systems. If you configure this policy setting, an audit event is generated when sensitive privilege requests are made.

Network activity

The following network activity policy settings allow you to monitor security-related issues that are not necessarily covered in the data or user activity categories, but that can be equally important for network status and protection.

• Account Management. The policy settings in this category can be used to track attempts to create, delete, or modify user or computer accounts, security groups, or distribution groups. Monitoring these activities complements the monitoring strategies you select in the user activity and data activity sections.

• Account Logon\Audit Kerberos Authentication Service and Account Logon\Audit Kerberos Service Ticket Operations. Audit policy settings in the Account Logon category monitor activities relating to the use of domain account credentials. These policy settings complement the policy settings in the Logon/Logoff category. The Audit Kerberos Authentication Service policy setting allows you to monitor the status of and potential threats to the Kerberos service. The Audit Kerberos Service Ticket Operations policy setting allows you to monitor the use of Kerberos service tickets.

• Account Logon\Audit Other Account Logon Events. This policy setting can be used to track a number of different network activities, including attempts to create Remote Desktop connections, wired network connections, and wireless connections.

• DS Access. Policy settings in this category allow you to monitor the AD DS role services, which provide account data, validate logons, maintain network access permissions, and provide other services that are critical to the secure and proper functioning of a network. Therefore, auditing the use of privileges to access and modify the configuration of a domain controller can help an organization maintain a secure and reliable network. In addition, one of the key tasks performed by AD DS is the replication of data between domain controllers.

• Logon/Logoff\Audit IPsec Extended Mode, Logon/Logoff\Audit IPsec Main Mode, and Logon/Logoff\Audit IPsec Quick Mode. Many networks support large numbers of external users, including remote employees and partners. Because these users are outside the organization's network boundaries, IPsec is often used to help protect communications over the Internet by enabling network-level peer authentication, data origin authentication, data integrity, data confidentiality (encryption), and protection against replay attacks. You can use these settings to ensure that IPsec services are functioning properly.

• Logon/Logoff\Audit Network Policy Server. Organizations that use RADIUS (IAS) and Network Access Protection (NAP) to set and maintain security requirements for external users can use this policy setting to monitor the effectiveness of these policies and to determine whether anyone is attempting to circumvent these protections.

• Policy Change. Policy Change policy settings and events allow you to track changes to important security policies on a local computer or network. Because policies are typically established by administrators to help secure network resources, any changes or attempts to change these policies can be an important aspect of security management for a network.

• Policy Change\Audit Audit Policy Change. This policy setting allows you to monitor changes to the audit policy. If malicious users were to obtain domain administrator credentials, they could temporarily disable essential security audit policy settings so that their other activities on the network could not be detected.

• Policy Change\Audit Filtering Platform Policy Change. This policy setting can be used to monitor a large variety of changes to an organization's IPsec policies.

• Policy Change\Audit MPSSVC Rule-Level Policy Change. This policy setting determines whether the operating system generates audit events when changes are made to policy rules for the Microsoft Protection Service (MPSSVC.exe), which is used by Windows Firewall. Changes to firewall rules are important to understand the security state of the computer and how well it is protected against network attacks.

Confirm operating system version compatibility

Not all versions of Windows support advanced audit policy settings or the use of Group Policy to apply and manage these settings. The basic security audit policy settings can be used to log audit events on any computer running Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows 2000 Server, or any computer running Windows 2000, Windows Vista, or Windows 7 that can join a domain. The Advanced Audit Policy Configuration policy settings can be applied via a logon script on computers running Windows Vista or Windows Server 2008 and via Group Policy on computers running Windows Server 2008 R2 or Windows 7. For more information, see Which Versions of Windows Support Advanced Audit Policy Configuration?

The audit policy settings under Local Policies\Audit Policy overlap with audit policy settings under Security Settings\Advanced Audit Policy Configuration. However, the advanced audit policy categories and subcategories make it possible to focus your auditing efforts on the most critical activities while reducing the amount of audit data that is less important to your organization.

For example, Local Policies\Audit Policy contains a single setting called Audit account logon events, which when configured generates at least 10 different types of audit events.

In comparison, the Account Logon category under Security Settings\Advanced Audit Policy Configuration allows you to focus your auditing on:

• Credential Validation

• Kerberos Authentication Service

• Kerberos Service Ticket Operations

• Other Account Logon Events

Each of these advanced settings allows you to exercise a much tighter control over what activities or events generate event data and which do not. Some activities and events will be more important to your organization than others, so define the scope of your security audit policy as narrowly as possible. Also, if you have not done so already, consider upgrading the computers that contain your organization's most critical resources so that you can use Group Policy to apply and manage audit policy for these resources.

Success, failure, or both

Whichever event settings you include in your plan, you also have to decide whether you want to log an event when the activity fails, when an activity succeeds, or both successes and failures. This is an important question, and the answer will be based on the criticality of the event and the implications of the decision on event volume.

For example, on a file server that is accessed frequently by legitimate users, you may be interested in logging an event only when an unsuccessful attempt to access data takes place, because this could be evidence of an unauthorized or malicious user. And in this instance logging successful attempts to access the server would quickly fill the event log with benign events.

On the other hand, if the file share has extremely sensitive and valuable information, such as trade secrets, then you may want to log every access attempt, whether successful or unsuccessful, so that you have an audit trail of every user who accessed the resource.

For more information about the impact and volume of audit events triggered by different audit policy settings, see Security Audit Policy Reference.

Planning for security audit monitoring and management

Networks can contain hundreds of servers running critical services or storing critical data, all of which need to be monitored. The number of client computers on the network can easily range into the tens or even hundreds of thousands. This may not be an issue if the ratio of servers or client computers per administrator is low. Even if an administrator who is responsible for auditing security and performance issues has relatively few computers to monitor, you need to decide how an administrator will obtain event data to review. The following are some options for obtaining the event data:

• Will you keep event data on a local computer until an administrator logs on to review this data? If so, then the administrator needs to have physical or remote access to the Event Viewer on each client computer or server, and the remote access and firewall settings on each client computer or server need to be configured to enable this access. In addition, you will need to decide how often an administrator can visit each computer, and adjust the size of the audit log so that critical information is not deleted if the log reaches its maximum capacity.

• Will you collect event data so that it can be reviewed from a central console? If so, there are a number of computer management products, such as the Audit Collection Services in Microsoft System Center Operations Manager 2007, which can be used to collect and filter event data. Presumably this solution enables a single administrator to review larger amounts of data than using the local storage option. But in some cases this can make it more difficult to detect clusters of related events that can occur on a single computer. For more information, see Audit Collection Services (ACS) (https://go.microsoft.com/fwlink/?LinkId=163436).

In addition, whether you choose to leave audit data on an individual computer or consolidate it at a central location, you need to decide how large the log file should be and what should happen when the log reaches its maximum size. To configure these options, open Event Viewer, expand Windows Logs, right-click Security, and click Properties. You can configure the following properties:

• Overwrite events as needed (oldest events first). This is the default option, which is an acceptable solution in most situations.

• Archive the log when full, do not overwrite events. This option can be used when all log data needs to be saved, but it also suggests that you may not be reviewing audit data frequently enough.

• Do not overwrite events (Clear logs manually). This option stops the collection of audit data when the log file reaches its maximum size. Older data is retained at the expense of the most recent audit events. Use this option only if you do not want to lose any audit data, do not want to create an archive of the event log, and are committed to reviewing data before the maximum log size is reached.

You can also configure the audit log size and other key management options by using Group Policy. You can configure the event log settings in the following locations within the GPMC: Computer Configuration\Administrative Templates\Windows Components\Event Log Service\Security. These options include:

• Maximum Log Size (KB). This policy setting specifies the maximum size of the log files. The user interfaces (UIs) of both the Local Group Policy Editor and the Microsoft Management Console (MMC) Event Viewer snap-in allow you to enter values as large as 2 terabytes. If this setting is not configured, event logs have a default maximum size of 20 megabytes.

• Log Access. This policy setting determines which user accounts have access to log files and what usage rights are granted.

• Retain old events. This policy setting controls event log behavior when the log file reaches its maximum size. When this policy setting is enabled and a log file reaches its maximum size, new events are not written to the log and are lost. When this policy setting is disabled and a log file reaches its maximum size, new events overwrite old events.

• Backup log automatically when full. This policy setting controls event log behavior when the log file reaches its maximum size and takes effect only if the Retain old events policy setting is enabled. If you enable this policy setting and the Retain old events policy setting is enabled, the event log file is automatically closed and renamed when it is full. A new file is then started. If you disable or do not configure this policy setting and the Retain old events policy setting is enabled, new events are discarded and the old events are retained.

For more information about the potential vulnerabilities addressed by these settings and their potential impacts, see the Threats and Countermeasures Guide: Security Settings in Windows Server 2008 and Windows Vista.

In addition, a growing number of organizations are being required to store archived log files for a number of years. You should consult with regulatory compliance officers in your organization to determine whether such guidelines apply to your organization. For more information, see the IT Compliance Management Guide (https://go.microsoft.com/fwlink/?LinkId=163435).

Deploying the security audit policy

Before deploying the audit policy in a production environment, it is critical that you determine the effects of the policy settings that you have configured.

The first step in assessing your audit policy deployment is to create a test environment in a lab and use it to simulate the various use scenarios that you have identified to confirm that the audit settings that you have selected are configured correctly and generate the type of results you intend. For more information about setting up a lab environment for testing security audit policy, see the Advanced Security Audit Policy Step-by-Step Guide.

However, unless you are able to run fairly realistic simulations of network usage patterns, a lab setup cannot provide you with accurate information about the volume of audit data that the audit policy settings you selected will generate and how effective your plan for monitoring audit data will be. To provide this type of information, you need to conduct one or more pilot deployments. These pilot deployments could involve:

• A single OU containing critical data servers or an OU containing all desktop computers in a specified location.

• A limited set of security audit policy settings, such as Logon/Logoff and Account Logon.

• A combination of limited OUs and audit policy settings; for example, targeting servers in the Accounting OU only with Object Access policy settings.

After you have successfully completed one or more limited deployments, you should confirm that the audit data that is collected is manageable with your management tools and administrators. When you have confirmed that the pilot deployment is effective, you need to confirm that you have the tools and staff to expand the deployment to include additional OUs and sets of audit policy settings until the production deployment is complete.

For more information about modeling and deploying Group Policy, see the Group Policy Planning and Deployment Guide.

Additional resources

• Security and Protection

• Auditing Security Events Best Practices

• Windows Security Logging and Other Esoterica (https://go.microsoft.com/fwlink/?LinkId=163437)

• Auditing Security Events (https://go.microsoft.com/fwlink/?LinkId=163438)