Submit a ticketCall us

Announcing NCM 7.7
With NCM 7.7, you can examine the rules that make up an access control list for a Cisco ASA device. Then you can apply filters to display only rules that meet the specified criteria, order the rules by line number or by the hit count, and much more.
See new features and improvements.

Home > Success Center > Log & Event Manager (LEM) > Audit Policies and Best Practices for LEM

Audit Policies and Best Practices for LEM

Updated December 27, 2016

Introduction

Windows Audit Policy is used to determine the verbosity of Windows Security Logs on domain controllers and other computers on the domain. The recommendations in this document have been found to be most effective from both a best practice and compliance standpoint and are based on customer experience and recommendations from Microsoft.

Requirements

Setting Windows Audit Policy for use with the SolarWinds Log & Event Manager requires the following.

  • Active Directory deployed. Policies can be at the local machine if AD is not deployed.
  • Windows Server 2003 or higher.
  • Permissions to change Windows Audit Policy at the domain, site, or OU level using Group Policy Management or similar application.
  • Access to the web-based LEM console or the Adobe-Air-based LEM console.

Windows Audit Policy Definitions

This section is adapted from information available at:
http://technet.microsoft.com  (© 2016 Microsoft, available at http://technet.microsoft.com, obtained on December 27, 2016.)

You can find relevant articles by searching for audit policy best practice from the page linked above.

Audit account logon events

Logon events represent instances of users logging on to or logging off from a computer that is logging those events. Account logon events are specifically related to domain logon events and are logged in the security log for the related domain controller.

Audit account management

Account management events are the “change management” events on a computer. These events include all changes made to users, groups and machines.

Audit logon events

Logon events represent instances of users logging on to or logging off from a computer that is logging those events. Events in this category are logged in the security log of the local computer onto which the user is logging, even when the user is actually logging onto the domain using their local computer.

Audit object access

Object access events track users accessing objects that have their own system access control lists. Such objects include files, folders and printers.

Audit policy change

Policy change events represent instances in which local or group policy is changed. These changes include changes to user rights assignments, audit policies and trust policies.

Audit privilege use

Privilege use events track users accessing objects based on their level of privilege to do so. Such objects include files, folders and printers, or any object that has its own system access control list defined.

Audit process tracking

Process tracking logs all instances of process, service and program starts and stops. This can be useful to track both wanted and unwanted processes such as AV services and malicious programs, respectively.

Audit system events

System events include start up and shut down events on the computer logging them, along with events that affect the system’s security. These are operating system events and are only logged locally.

Windows Audit Policy Best Practice

Windows Audit Policy is defined locally for each computer, but we recommend using Group Policy to manage the Audit Policy at both the domain controller and domain levels.

To set Windows Audit Policy using Group Policy Object Editor:

  1. Expand Computer Configuration > Windows Settings > Security Settings > Local Policies and select Audit Policy in the left pane.
  2. Select the policy you want to define in the right pane and click Properties on the Action menu.
  3. Select or clear Success and Failure according to the instructions below.

Default Domain Controllers Policy

Select Success and Failure for all policies except:

  • Audit object access
  • Audit privilege use

For these, only select Failure.

Default Domain Policy

Default Domain Policy applies to all computers on your domain except your domain controllers.

For this policy, select Success and Failure for the following:

  • Audit account logon events
  • Audit account management
  • Audit logon events
  • Audit policy change
  • Audit system events

You may also select Success and Failure for Audit process tracking to monitor critical processes such as the AV service or unauthorized programs such as games or malicious executable files.

Note: Enabling auditing at the level of Audit process tracking will significantly increase the number of events in the system logs. Therefore, Your LEM database will grow more quickly as it collects these logs. Similarly, there could be bandwidth implications as well. This is wholly dependent upon your network’s traffic volume and bandwidth capacity. Since agent traffic is transmitted to the manager as a real time “trickle” of data, bandwidth impact is typically minimal

 

Changing from Category-Level Auditing to Sub-Category Auditing

With Windows 2008 and newer operating systems, Microsoft introduced sub-category auditing. Enabling auditing at the category-level will automatically enable all sub-categories. This can result in a higher than expected auditing level. Enabling the sub-category-level auditing will automatically disable the category-level auditing and allow you to fine tune the auditing. Before enabling the subcategory, we recommend setting the sub-category auditing before enabling the sub-category. We provide the PCI auditing settings as a reference, and you can adjust to meet your auditing requirements or to fulfill your auditing preferences.

 

Open the Group Policy Management Console (or gpedit.msc if not using AD), and go to:

     To change the sub-category settings:

          Computer-Configuration  >  Windows-Settings  >  Security-Settings  > Advanced Audit Policy Configuration

     To enable the sub-category auditing (which disables the category-level auditing):

          Computer-Configuration  >  Windows-Settings  >  Security-Settings  >  Local-Policies  >  Security-Options  >  Audit:Force-audit-policy-subcategory-settings  ==> enabled

PCI-DSS  log selection

     PCI Compliance and Log and Event Manager

Category / Subcategory
Setting
System
 
Security System Extension No Auditing
System Integrity Success and Failure
IPsec Driver No Auditing
Other System Events No Auditing
Security State Change Success and Failure
Logon/Logoff
 
Logon Success and Failure
Logoff Success and Failure
Account Lockout Success and Failure
IPsec Main Mode No Auditing
IPsec Quick Mode No Auditing
IPsec Extended Mode No Auditing
Special Logon Success and Failure
Other Logon/Logoff Events Success and Failure
Network Policy Server No Auditing
Object Access
 
File System Success and Failure
Registry Success and Failure
Kernel Object No Auditing
SAM No Auditing
Certification Services No Auditing
Application Generated No Auditing
Handle Manipulation No Auditing
File Share Success and Failure
Filtering Platform Packet Drop No Auditing
Filtering Platform Connection No Auditing
Other Object Access Events No Auditing
Detailed File Share No Auditing
Privilege Use
 
Sensitive Privilege Use Failure
Non Sensitive Privilege Use No Auditing
Other Privilege Use Events No Auditing
Detailed Tracking
 
Process Termination No Auditing
DPAPI Activity No Auditing
RPC Events No Auditing
Process Creation No Auditing
Policy Change
 
Audit Policy Change Success and Failure
Authentication Policy Change Success and Failure
Authorization Policy Change Success and Failure
MPSSVC Rule-Level Policy Change No Auditing
Filtering Platform Policy Change No Auditing
Other Policy Change Events Success and Failure
Account Management
 
User Account Management Success and Failure
Computer Account Management Success and Failure
Security Group Management Success and Failure
Distribution Group Management Success and Failure
Application Group Management Success and Failure
Other Account Management Events Success and Failure
DS Access
 
Directory Service Changes No Auditing
Directory Service Replication No Auditing
Detailed Directory Service Replication No Auditing
Directory Service Access Failure
Account Logon
 
Kerberos Service Ticket Operations Success and Failure
Other Account Logon Events Success and Failure
Kerberos Authentication Service Success and Failure
Credential Validation Success and Failure

Note: The above auditing includes disabling 9 of the sub-categories that create noise from Windows Filtering Platform. Not disabling this 'noise' can cause in a higher level of events being sent to the LEM, rules firing needlessly, the need for increased resource reservations in the LEM, and excessive number of events logged internally in the Windows security event log.

 

Dropping events at the entrance to the LEM
Some auditing can be dropped as the event is received by the LEM. Dropping events at the LEM will still require resources on the LEM to accomplish this task, and we advise caution to avoid failing auditing requirements. An example of events that might be dropped would be the Machine Logon and Machine Logoff (if allowed by auditing requirements).
Open the LEM GUI-console, select Manage > Appliances, and select Policy from the gear on the left.

     Machine Logon          ==>  Generic Alert  >  Audit Alert  >  Auth Audit  >  Machine Auth Audit  >  Machine Logon
     Machine Logoff          ==>  Generic Alert   >  Audit Alert  >  Auth Audit  >  Machine Auth Audit  >  Machine Logoff
     Machine Auth Ticket  ==>  Generic Alert  >  Audit Alert  >  Auth Audit  >  Machine Auth Audit  >  Machine Auth Ticket

uncheck the check boxes for the following  =>  console / database / warehouse / rules

 

Disclaimer: Please note, any content posted herein is provided as a suggestion or recommendation to you for your internal use. This is not part of the SolarWinds software or documentation that you purchased from SolarWinds, and the information set forth herein may come from third parties. Your organization should internally review and assess to what extent, if any, such custom scripts or recommendations will be incorporated into your environment.  You elect to use third party content at your own risk, and you will be solely responsible for the incorporation of the same, if any.

 

Last modified
10:55, 27 Dec 2016

Tags

Classifications

Public