This page explains following options, available on Audit Policy Configuration page:

Audit Policy

A major function of the Snare system is to filter events.  This is accomplished via the advanced auditing 'audit policies' also known as 'objectives' capability in previous releases.  Any number of audit policies may be specified and are displayed on the Audit Policy Configuration page. The agent can operate either with windows basic auditing or advanced auditing (licence feature) options. By default a set of audit policies is available with the Snare Enterprise Agent for Windows installation.

Basic Auditing

Audit policy configuration page will look like as follows if the agent is using basic auditing. 

To create a new audit policy click Add Audit Policy, or to view/edit an existing audit policy select Modify.  The following parameters may be set:

• Identify the high level event. Each of the audit policies provides a high level of control over which events are selected and reported.  Events are selected from a group of high level requirements and further refined using selected filters.  Only Windows Security Event Log events are contained within the high level groups.  Details on which Windows Event Log event IDs are used to generate the following audit policies can be found in Appendix C - Audit Policies and security event IDs:
  • Logon or Logoff
  • Account administration
  • Change the security policy
  • Start or stop a process
  • Restart, shutdown and system
  • Use of user rights
  • Filtering platform events
  • USB event
  • Other object access events
  • Any event(s).

The above groups are provided to service the most common security audit policies that are likely to be encountered.  If other event types are required, then the Any event(s) audit policy will allow fully tailored audit policies to be set. 

Advanced Auditing (Licensed Feature)

Audit policy configuration page will look like as follows if the agent is using advanced auditing. 

To create a new audit policy click Add Advanced Policy, or to view/edit an existing audit policy select Modify.  The following parameters may be set:

• Identify the high level event. Each of the audit policies provides a high level of control (Sub-category) over which events are selected and reported.  Events are selected from a group of high level requirements and further refined using selected filters.  Details on which high level event (Sub-category) generate with events can be found in https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-audit-policy-settings. 
• The new advanced auditing policies also include the medium and high rated critical events that Microsoft also recommend to collect from systems. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor

Common Filters

The following filters can be applied to incoming audit events with both advanced and basic auditing options:

• Event ID Search Term. Each event contains a unique number known as the Event ID. If the high level event Any event(s) is selected, then the user is able to filter on the EventID field. If multiple events are required, the user may enter the event IDs as a comma separated string. Example: 562,457,897. Using the wildcard character '*' will select all events. Use the wildcard with caution since ALL events will be collected and passed to the remote host. For all other high level events, this field is ignored and automatically managed by the agent.
  The user may select whether to include or exclude messages that match this audit policy. If an audit policy is set to 'Exclude', matching event logs will be immediately discarded. Note: Ensure the Perform a scan of ALL audit policies configuration option is disabled in the Network Configuration window.

• General Search Term.  This allows the user to further refine a search based on the event record payload. For most high level events, this option will search all the fields of an event record, except the header. For simple searches (i.e. not a regular expression), there is NO need to use the wildcard character at the start or end of this field as it is automatically added to the search term when the audit policy is saved. The user may select whether to include or exclude messages that match this audit policy by selecting the Include or Exclude radio buttons.
  
  The search string may be treated as a Perl Compatible Regular Expression if the Regular Expression checkbox is selected.  This allows more powerful and refined text matching and targeted audit policies allowing sophisticated forensic analysis and reporting, particularly when small details get lost in noisy log environments. Some common useful regular expressions include: 
     Event contains email address:

([a-z0-9_\.-]+@([\da-z\.-]+\.([a-z\.]{2,6})

     Event contains URL:

(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?

     Event contains IP address:

(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)

     Event contains hex-numbers:

#?([a-f0-9]{6}|[a-f0-9]{3})

• User Search Term.   An event record may be selected or discarded based on a userid, or partial match of a userid. If no users are entered AND the Include radio button has been selected, then ALL users will be audited. If a term is entered in this field, then an event record will be trapped or discarded based on a valid match and whether the Include or Exclude radio buttons have been selected. There is no need to use the wildcard character at the start and end of this field as it is automatically added when the audit policies is saved. Multiple users may be entered using a comma separated list.
  
  
• Source Search Term. This feature is relevant for Windows Vista/2008 and above, where much of the key information is buried in the Applications and Services logs. See Custom Event Log for further details.
  For example to include the events in DNS Server as displayed below, then the Source Search Term should be set to * and the event log source should be checked for DNS Server.
  

Latest events window displays the Source Name as below:

• Identify the event types to be captured. Windows uses many different audit event types, including:
  
  • Success Audit
  • Failure Audit
  • Information
  • Warning
  • Error
  • Critical
  • Verbose
  • Activity Tracing.
  Below is an example of a logged event in Event Viewer. The Level: field displays this event type as Information.  If it is unclear which type of event is required, then selecting all of the check boxes will ensure that no events are lost. Note if none of the checkboxes are selected, then no events will be trapped.
  
  
• Identify log sources to capture events from. Windows collects logs from a number of event log sources. On Windows Servers, all the primary event logs may be found, however on pre-Vista Workstation installations only three of these event logs (Security, System and Application) are available. The event log options are:
  
  • Security
  • System
  • Application
  • Directory Service
  • DNS Server
  • DFS Replication
  • Legacy FRS
  • Custom Event Log (see below for further information)
  
  If in doubt, there will be no harm done in selecting all event log types, except that Snare will now read from, and attempt to filter, from all the selected event logs and this will have some slight negative performance impact. Please note, if any high level event except for Any event(s) is selected, then this item is pre-selected automatically by the high level event. This option can be used to apply additional filtering by log source. 
  
  
• Select the Alert Level.  A criticality level may be assigned to enable the Snare user to designate audit events to their most pressing business security audit policies , and to quickly identify the level of importance via the criticality options in the drop down list.  The Latest Events page will highlight the event in the selected Snare criticality color assigned to your audit policy. User can choose the criticality level depending on the destination the event is being sent. There are options to assign criticality for each destination based on the format Snare, Syslog, CEF or LEEF. Each of these criticalites is then assigned to the event. While sending to the destination, specific criticality is assigned to the final event string depending on the destination type ie Snare, Syslog, CEF or LEEF.

• • Snare - Critical, Priority, Warning, Information, Clear
  • Syslog - Emergency, Alert, Critical, Error, Warning, Notice, Info, Debug
  • CEF - 0 - 10, 0 is least severe and 10 is most severe.
  • LEEF - 1 - 10, 1 is least severe and 10 is most severe.
    
    

File/Folder and Registry Activity Monitoring (FAM and RAM)

Starting from Snare Agent v5.6.0, an easy to use GUI is added to enable File/Folder Activity Monitoring (FAM) and Registry Activity Monitoring (RAM). The GUI buttons 'Add FAM Policy' and 'Add RAM Policy' can be used to enable a FAM/RAM policy on the given file/folder/registry key. If a FAM/RAM policy was added in pre v5.6.0 using the option 'Access File or Directory' then such FAM/RAM policies will appear under File Activity Monitoring (FAM) Policies section after upgrade to v5.6.0. 

File Activity Monitoring (FAM)

'Add FAM Policy' button shows the following GUI. This GUI can be used to enable the FAM policy on a file or folder.

• Audit Policy Type: Select the type of audit policy that needs to be created
• File or Folder: The full path of the file/folder that needs to be monitored
• Event Type: Types of the FAM events that need to be captured
• FAM Scope: The scope of the FAM policy i.e. the file/folders on which that FAM policy needs to be applied
• Permissions: The permissions that need to be monitored for the file/folder
• General Search Term: Works the same way as for audit objective
• User Search Term: Works the same way as for audit objective
• Select the Alert Level: Works the same way as for audit objective

Registry Activity Monitoring (RAM)

'Add RAM Policy' button shows the following GUI. This GUI can be used to enable the RAM policy on a registry key

• Registry Key: The full path of the registry key that needs to be monitored. The parent registry hive should be selected from drop-down and rest of the path should be entered in text box i.e. Software\Policies\Microsoft
• Event Type: Types of the RAM events that need to be captured
• RAM Scope: The scope of the RAM policy i.e. the registry key/sub-keys on which that RAM policy needs to be applied
• Permissions: The permissions that need to be monitored for registry
• General Search Term: Works the same way as for audit objective
• User Search Term: Works the same way as for audit objective
• Select the Alert Level: Works the same way as for audit objective

To save and set the changes to the above settings, and to ensure the audit daemon has received the new configuration perform the following:

1. Click on Change Configuration to save any changes to the registry.
2. Click on the Apply Configuration & Restart Service menu item.

   Note

   Please Note its not advisable to do auditing on the entire AuditService registry tree, The Status sub tree location is updated as part of the agent sending logs. Monitoring this location will result in a loop condition of the agent monitoring changes then sending logs causing more logs to be be sent then causing more audit events. Any high activity registry keys can have this affect.