first edit pass

windows/security/threat-protection/auditing/planning-and-deploying-advanced-security-audit-policies.md

@@ -1,6 +1,6 @@
 ---
 title: Plan and deploy advanced security audit policies (Windows 10)
-description: Learn which options to consider and tasks to complete to deploy an effective security audit policy in a network that includes advanced security audit policies.
+description: Learn to deploy an effective security audit policy in a network that includes advanced security audit policies.
 ms.assetid: 7428e1db-aba8-407b-a39e-509671e5a442
 ms.reviewer: 
 ms.author: dansimp
@@ -22,14 +22,13 @@ ms.date: 04/19/2017
 **Applies to**
 -   Windows 10
 
-This topic for the IT professional 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 advanced security audit
-policies.
+This topic for the IT professional explains the options that security policy Class Schedules must consider and the tasks they must complete to deploy an effective security audit policy in a network that includes advanced security audit policies.
 
-Organizations invest a large portion of their information technology budgets on security applications and services, such as antimalware software, firewalls, and encryption. But no matter how much security hardware or software you deploy, how tightly you control the rights of users, or how 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.
+Organizations invest a lot in security applications and services, such as antimalware software, firewalls, and encryption. But no matter how much security hardware or software you deploy, how tightly you control the rights of users, or how carefully you configure security permissions on your data, the job isn't 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 for 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.
 
-No organization has unlimited resources to monitor every resource and activity on a network. If you don't plan well, you will likely have gaps in your auditing strategy. However, if you try to audit every resource and activity, you may find yourself with too much monitoring data, including thousands of benign audit entries that an analyst needs 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. So, too much monitoring can leave an organization as vulnerable as not enough.
+No organization has unlimited resources to monitor every resource and activity on a network. If you don't plan well, you will likely have gaps in your auditing strategy. However, if you try to audit every resource and activity, you may find yourself with too much monitoring data, including thousands of benign audit entries that an analyst needs to sift through to identify the narrow set of entries that warrant closer examination. This volume could cause delays or even prevent auditors from identifying suspicious activity. So, too much monitoring can leave an organization as vulnerable as not enough.
 
 Here are some features that can help you focus your effort:
 
@@ -59,13 +58,13 @@ This document guides you through the steps to plan a security auditing policy th
 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
+-   Storing and (if necessay) 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.
 
 ## Understand the security audit policy design process
 
-Designing and deploying a Windows security audit policy involves the following tasks, which are described in in this document:
+Designing and deploying a Windows security audit policy involves the following tasks, which are described in this document:
 
 -   [Identify your Windows security audit policy deployment goals](#bkmk-1)
 
@@ -101,7 +100,7 @@ To create your Windows security audit plan, begin by identifying:
 
 ### Network environment
 
-An organization's domain and organziational unit (OU) structure provide a fundamental starting point for thinking about how to apply a 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's 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 security audit policy to groups of users, computers, and resources in your organization](#bkmk-2) later in this document.
+An organization's domain and organizational unit (OU) structure provide a fundamental starting point for thinking about how to apply a 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's 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 security audit policy to groups of users, computers, and resources in your organization](#bkmk-2) 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 that you can define and apply audit settings that enhance the organization's ability to identify and counter those threats.
 
@@ -188,7 +187,7 @@ For more information, see the [System Center Process Pack for IT GRC](https://te
 By using Group Policy, you can apply your security audit policy to defined groups of users, computers, and resources. To map a security auditing policy to these defined groups in your organization, you should understand the following considerations for using Group Policy to apply security audit policy settings:
 
 -   The policy settings you identify can be applied by 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.
--   You need to decide whether every policy setting that you select should be enforced across the organization or apply only to selected users or computers. You can then combine these audit policy settings into GPOs and link them to the appropriate Active Directory containers.
+-   Decide whether every policy setting that you select should be enforced across the organization or apply only 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 that are linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, a GPO that is linked at a lower level can overwrite inherited policies.
 
     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 do this, you can link a second GPO to that specific lower-level OU. Then, 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).
@@ -197,17 +196,17 @@ By using Group Policy, you can apply your security audit policy to defined group
 
     For example, you could configure a SACL for a folder called Payroll Data on Accounting Server 1. This can audit attempts by members of the Payroll Processors OU to delete objects from this folder. The **Object Access\\Audit File System** audit policy setting applies to 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 generate audit events.
 
--   Advanced security audit policy settings were introduced in Windows Server 2008 R2 or Windows 7 and can be applied to those operating systems and later. These advanced audit polices can only be applied by using Group Policy.
+-   Advanced security audit policy settings were introduced in Windows Server 2008 R2 or Windows 7 and can be applied to those operating systems and later. These advanced audit policies can only be applied by using Group Policy.
 
     >[!IMPORTANT]  
     > Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both basic and advanced audit policy settings can cause unexpected results in audit reporting.
 
-    If you use **Advanced Audit Policy Configuration** settings or logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
+    If you use **Advanced Audit Policy Configuration** settings or logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This configuration will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
      
 
 The following examples show how you can apply audit policies to an organization's OU structure:
 
--   Apply data activity settings to an OU that contains file servers. If your organization has servers that contain 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 data activity settings to an OU that contains file servers. If your organization has servers that contain 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 policies to an OU that contains 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 that are accessed by employees who work in more sensitive areas, such as network administrators or the legal department.
 -   Apply network and system activity audit policies to OUs that contain the organization's most critical servers, such as domain controllers, CAs, email servers, or database servers.
 
@@ -244,7 +243,7 @@ Depending on your goals, different sets of audit settings may be of particular v
 
 ### 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 must be protected against any breach, the following settings can provide extremely valuable monitoring and forensic data:
+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 must be protected against any breach, the following settings can provide valuable monitoring and forensic data:
 
 -   **Object Access\\[Audit File Share](audit-file-share.md)**: This policy setting allows you to track what content was accessed, the source (IP address and port) of the request, and the user account that was used for the access. The volume of event data generated by this setting will vary depending on the number of client computers that 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 that have permissions on the file share, you may want to log audit events only for failed attempts to access the file share.
 -   **Object Access\\[Audit File System](audit-file-system.md)**: 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 that's making the request match the settings in the SACL.
@@ -258,7 +257,7 @@ For many organizations, compromising the organization's data resources can cause
 
     Event volume can be high, depending on how the SACLs are configured. When used together with the **Audit File System** or **Audit Registry** policy setting, the **Audit Handle Manipulation** policy setting can provide an administrator with useful "reason for access" audit data that details 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 only the event but also the permissions that were used (or attempted to be used) to save the file changes.
 
--   **Global Object Access Auditing**: A growing number of organizations use security auditing to comply with regulatory requirements that govern data security and privacy. But demonstrating that strict controls are being enforced can be extremely difficult. To address this issue, the supported versions of Windows include two **Global Object Access Auditing** policy settings, one for the registry and one for the file system. When you configure these settings, they apply a global system access control SACL on all objects of that class on a system, which cannot be overridden or circumvented.
+-   **Global Object Access Auditing**: A growing number of organizations use security auditing to comply with regulatory requirements that govern data security and privacy. But demonstrating that strict controls are being enforced can be difficult. To address this issue, the supported versions of Windows include two **Global Object Access Auditing** policy settings, one for the registry and one for the file system. When you configure these settings, they apply a global system access control SACL on all objects of that class on a system, which cannot be overridden or circumvented.
     > [!IMPORTANT]
     > The **Global Object Access Auditing** policy settings must be configured and applied in conjunction with the **Audit File System** and **Audit Registry** audit policy settings in the **Object Access** category.
      
@@ -268,52 +267,53 @@ The settings in the previous section relate to activity involving the files, fol
 
 In the majority of cases, these attempts will be legitimate, and the network needs to make vital data readily available to legitimate users. However in other cases, 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](audit-credential-validation.md)**: 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 is attempting to use a variety of credentials in succession in hope that one of these attempts will eventually succeed. These events occur on the computer that's 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](audit-process-creation.md) and Detailed Tracking\\[Audit Process Termination](audit-process-termination.md)**: These policy settings enable you to monitor the applications that a user opens and closes on a computer.
--   **DS Access\\[Audit Directory Service Access](audit-directory-service-access.md)** and **DS Access\\[Audit Directory Service Changes](audit-directory-service-changes.md)**: These 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 permissions to modify AD DS objects, so it's 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.
+-   **Account Logon\\[Audit Credential Validation](audit-credential-validation.md)**: This is an  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 is attempting to use a variety of credentials in succession in hope that one of these attempts will eventually succeed. These events occur on the computer that's 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](audit-process-creation.md) and Detailed Tracking\\[Audit Process Termination](audit-process-termination.md)**: These policy settings enable you to monitor the applications that a user opens and close on a computer.
+-   **DS Access\\[Audit Directory Service Access](audit-directory-service-access.md)** and **DS Access\\[Audit Directory Service Changes](audit-directory-service-changes.md)**: These 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 permissions to modify AD DS objects, so it's 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](audit-account-lockout.md)**: Another common security scenario occurs when a user attempts to log on with an account that's been locked out. It's important to identify these events and to determine whether the attempt to use an account that has been locked out is malicious.
 -   **Logon/Logoff\\[Audit Logoff](audit-logoff.md)** and **Logon/Logoff\\[Audit Logon](audit-logon.md)**: 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 they 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 shared resource, events are generated on the computer that hosts the resource that was accessed. Logoff events are generated when logon sessions are terminated.
 
     >[!NOTE]
-    > There's no failure event for logoff activity because failed logoffs (such as when a system abruptly shuts down) do not generate an audit record. Logoff events are not 100-percent reliable. For example, the computer can be turned off without a proper logoff and shutdown, so a logoff event isn't generated.
+    > There's no failure event for logoff activity because failed logoffs (such as when a system abruptly shuts down) don't generate an audit record. Logoff events are not 100-percent reliable. For example, the computer can be turned off without a proper logoff and shutdown, so a logoff event isn't generated.
      
 -   **Logon/Logoff\\[Audit Special Logon](audit-special-logon.md)**: A special logon has administrator-equivalent rights and can be used to elevate a process to a higher level. It's recommended to track these types of logons.
--   Object Access\\[Audit Certification Services](audit-certification-services.md). This policy setting allows you to track and monitor a wide variety of activities on a computer that hosts 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](audit-file-system.md) and Object Access\\[Audit File Share](audit-file-share.md). These policy settings are described in the previous section.
--   Object Access\\[Audit Handle Manipulation](audit-handle-manipulation.md). This policy setting and its role in providing "reason for access" audit data is described in the previous section.
--   Object Access\\[Audit Registry](audit-registry.md). Monitoring for changes to the registry is one of the most critical means that an administrator has to ensure malicious users do not make changes to essential computer settings. Audit events are only generated for objects that have configured SACLs, and only if the type of access that is requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL.
+-   **Object Access\\[Audit Certification Services](audit-certification-services.md)**: This policy setting allows you to monitor a wide variety of activities on a computer that hosts Active Directory Certificate Services (AD CS) role services to ensure that only authorized users do these tasks and only authorized or desired tasks are done.
+-   **Object Access\\[Audit File System](audit-file-system.md) and Object Access\\[Audit File Share](audit-file-share.md)**: These policy settings are described in the previous section.
+-   **Object Access\\[Audit Handle Manipulation](audit-handle-manipulation.md)**: This policy setting and its role in providing "reason for access" audit data is described in the previous section.
+-   **Object Access\\[Audit Registry](audit-registry.md)**: Monitoring for changes to the registry is one of the most critical means that an administrator has to ensure malicious users don't make changes to essential computer settings. Audit events are only generated for objects that have configured SACLs and only if the type of access that is requested (such as *write*, *read*, or *modify*) and the account making the request match the settings in the SACL.
 
     > [!IMPORTANT]
-    > On critical systems where all attempts to change registry settings need to be tracked, you can combine the **Audit Registry** policy setting with the **Global Object Access Auditing** policy settings to ensure that all attempts to modify registry settings on a computer are tracked.
+    > On critical systems where all attempts to change registry settings should be tracked, you can combine the **Audit Registry** policy setting with the **Global Object Access Auditing** policy settings to ensure that all attempts to modify registry settings on a computer are tracked.
      
--   Object Access\\[Audit SAM](audit-sam.md). The Security Accounts Manager (SAM) is a database that is 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 the proper user rights 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](audit-sensitive-privilege-use.md). **Privilege Use** policy settings and audit events allow you to track the use of certain rights on one or more systems. If you configure this policy setting, an audit event is generated when sensitive rights requests are made.
+-   **Object Access\\[Audit SAM](audit-sam.md)**: The Security Accounts Manager (SAM) is a database 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 the proper user rights 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](audit-sensitive-privilege-use.md)**: These policy settings and audit events enable you to track the use of certain rights on one or more systems. If you configure this policy setting, an audit event is generated when sensitive rights 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.
+The following network activity policy settings enable 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](audit-kerberos-authentication-service.md) and Account Logon\\[Audit Kerberos Service Ticket Operations](audit-kerberos-service-ticket-operations.md). Audit policy settings in the **Account Logon** category monitor activities that relate 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 Management**: Use the policy settings in this category 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](audit-kerberos-authentication-service.md) and Account Logon\\[Audit Kerberos Service Ticket Operations](audit-kerberos-service-ticket-operations.md)**: Audit policy settings in the **Account Logon** category monitor activities that relate 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 enables 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.
 
-    >**Note:**  **Account Logon** policy settings apply only to specific domain account activities, regardless of the computer that is accessed, whereas **Logon/Logoff** policy settings apply to the computer that hosts the resources being accessed.
+    >[!NOTE] 
+    >**Account Logon** policy settings apply only to specific domain account activities, regardless of the computer that is accessed. **Logon/Logoff** policy settings apply to the computer that hosts the resources being accessed.
      
--   Account Logon\\[Audit Other Account Logon Events](audit-other-account-logon-events.md). 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 rights 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](audit-ipsec-extended-mode.md), Logon/Logoff\\[Audit IPsec Main Mode](audit-ipsec-main-mode.md), and Logon/Logoff\\[Audit IPsec Quick Mode](audit-ipsec-quick-mode.md). 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](audit-network-policy-server.md). 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**. These 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](audit-audit-policy-change.md). This policy setting allows you to monitor changes to the audit policy. If malicious users obtain domain administrator credentials, they can temporarily disable essential security audit policy settings so that their other activities on the network cannot be detected.
--   Policy Change\\[Audit Filtering Platform Policy Change](audit-filtering-platform-policy-change.md). 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](audit-mpssvc-rule-level-policy-change.md). This policy setting determines if 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 for understanding the security state of the computer and how well it is protected against network attacks.
+-   **Account Logon\\[Audit Other Account Logon Events](audit-other-account-logon-events.md)**: 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 enable 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 rights to access and modify the configuration of a domain controller can help an organization maintain a secure and reliable network. One of the key tasks performed by AD DS is the replication of data between domain controllers.
+-   **Logon/Logoff\\[Audit IPsec Extended Mode](audit-ipsec-extended-mode.md)**, **Logon/Logoff\\[Audit IPsec Main Mode](audit-ipsec-main-mode.md)**, and **Logon/Logoff\\[Audit IPsec Quick Mode](audit-ipsec-quick-mode.md)**: 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](audit-network-policy-server.md)** 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 trying to circumvent these protections.
+-   **Policy Change**: These policy settings and events enable 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](audit-audit-policy-change.md)**: This policy setting allows you to monitor changes to the audit policy. If malicious users obtain domain administrator credentials, they can temporarily disable essential security audit policy settings so that their other activities on the network can't be detected.
+-   **Policy Change\\[Audit Filtering Platform Policy Change](audit-filtering-platform-policy-change.md)**:.\ This policy setting can be used to monitor a variety of changes to an organization's IPsec policies.
+-   **Policy Change\\[Audit MPSSVC Rule-Level Policy Change](audit-mpssvc-rule-level-policy-change.md)**: This policy setting determines if 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 for understanding 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. For more info, see [Which editions of Windows support advanced audit policy configuration](which-editions-of-windows-support-advanced-audit-policy-configuration.md).
+Not all versions of Windows support advanced audit policy settings or the use of Group Policy to apply and manage these settings. For more information, see [Which editions of Windows support advanced audit policy configuration](which-editions-of-windows-support-advanced-audit-policy-configuration.md).
 
-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.
+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's less important to your organization.
 
-For example, **Local Policies\\Audit Policy** contains a single setting called [Audit account logon events](https://technet.microsoft.com/library/cc787176.aspx). When this setting is configured, it generates at least 10 types of audit events.
+For example, **Local Policies\\Audit Policy** contains a single setting called *[Audit account logon events](https://technet.microsoft.com/library/cc787176.aspx)*. When this setting is configured, it generates at least 10 types of audit events.
 
 In comparison, the Account Logon category under **Security Settings\\Advanced Audit Policy Configuration** provides the following advanced settings, which allow you to focus your auditing:
 
@@ -322,49 +322,50 @@ In comparison, the Account Logon category under **Security Settings\\Advanced Au
 -   Kerberos Service Ticket Operations
 -   Other Account Logon Events
 
-These settings allow you to exercise much tighter control over which activities or events generate event data. Some activities and events will be more important to your organization, so define the scope of your security audit policy as narrowly as possible.
+These settings enable you to exercise much tighter control over which activities or events generate event data. Some activities and events will be more important to your organization, so define the scope of your security audit policy as narrowly as possible.
 
-### Success, failure, or both
+### *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.
+For example, on a file server that's 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, 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.
+But if the file share has sensitive information, such as trade secrets, 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.
 
 ## <a href="" id="bkmk-4"></a>Plan 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. Following are some options for obtaining the event data.
+Networks can contain hundreds of servers running critical services or storing critical data, all of which need to be monitored. There may be tens or even hundreds of thousands on the network. These numbers 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 the administrator will obtain event data to review. 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 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 Operations Manager 2007 and 2012, 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.
+-   Will you keep event data on a local computer until an administrator logs on to review this data? If so, 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 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 Operations Manager 2007 and 2012, that 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 method can make it more difficult to detect clusters of related events that can occur on a single computer.
 
-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:
+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 select **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.
+-   **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 don't want to lose any audit data, don't 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 settings. You can configure the event log settings in the following locations within the GPMC: **Computer
+You can also configure the audit log size and other key management options by using Group Policy settings. You can configure the event log settings in the following location in 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 in the Local Group Policy Editor and Event Viewer allow you to enter values as large as 2 TB. If this setting is not configured, event logs have a default maximum size of 20 megabytes.
+-   **Maximum Log Size (KB)**: This policy setting specifies the maximum size of the log files. The user interfaces in the Local Group Policy Editor and Event Viewer allow you to enter values as large as 2 TB. 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 these policy settings, 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.
+-   **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 these policy settings, 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.
 
-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/p/?LinkId=163435).
+In addition, a growing number of organizations are being required to store archived log files for a number of years. 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/p/?LinkId=163435).
 
 ## <a href="" id="bkmk-5"></a>Deploy 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 you have selected are configured correctly and generate the type of results you intend.
+Before deploying the audit policy in a production environment, it's critical that you determine the effects of the policy settings that you have configured.
 
-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:
+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've identified to confirm that the audit settings you selected are configured correctly and generate the type of results you want.
+
+However, unless you are able to run fairly realistic simulations of network usage patterns, a lab setup can't provide 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 that contains critical data servers or an OU that contains 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 only the Accounting OU 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 necessary tools and staff to expand the deployment to include additional OUs and sets of audit policy settings until the production deployment is complete.
+After you successfully complete 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've confirmed that the pilot deployment is effective, you need to confirm that you have the necessary tools and staff to expand the deployment to include additional OUs and sets of audit policy settings until the production deployment is complete.