Skip to content

Audit Policies

Audit Policies are rule-based filters that determine which Windows security events collected by EventLogAgent clients are forwarded to LT Auditor MP or the configured syslog destination. Each policy applies an ALLOW or DENY action based on conditions evaluated against incoming events, giving administrators precise control over which events are forwarded and which are suppressed.

Understanding audit policy logic:

Audit policies use a two-level rule structure:

Rule Sets: Each policy contains one or more Rule Sets. Rule Sets use OR logic — if any Rule Set within a policy matches an incoming event, the policy action is applied.

Conditions: Each Rule Set contains one or more Conditions. Conditions within a Rule Set use AND logic — all conditions in a Rule Set must match for the Rule Set to trigger.

This structure allows complex filtering logic to be expressed clearly:

Policy matches if:

  (Condition A AND Condition B)   ← Rule Set 1

  OR

  (Condition C AND Condition D)   ← Rule Set 2

ALLOW vs DENY:

Action Description
ALLOW Matching events are forwarded to the configured target
DENY Matching events are suppressed and not forwarded

Accessing audit policy configuration for a group:

  1. In the left navigation menu, click Groups
  2. Locate the group you want to configure
  3. Click the ⋮ menu next to the group
  4. Select Audit Policies

Creating a new audit policy:

  1. Click Add Policy
  2. Configure the policy details:
    • Policy Name — a descriptive name that clearly indicates the policy’s purpose (e.g., Suppress Service Account Logons, Alert Privileged Logons)
    • Action — select ALLOW to forward matching events or DENY to suppress them
  3. Click Add Rule Set to add the first rule set
  4. Enter a Rule Set Name (e.g., Service Account Pattern)
  5. Add conditions to the rule set:
    • Click Add Condition
    • Select a Field from the available event fields:
Field Description
EventID The Windows Event ID
TargetUserName The username associated with the event
LogonType The logon type code (e.g., 2 = Interactive, 3 = Network)
PrivilegeList Privileges associated with the event
ProcessName The name of the process that generated the event
  • Select an Operator:
Operator Description
Equals Exact match
Contains Partial text match
StartsWith Matches text at the beginning of the field value
EndsWith Matches text at the end of the field value
Regex Match using a regular expression pattern
  • Enter the Value to match against
  • Click Save Condition
  1. Add additional conditions to the same rule set as needed — all conditions in a rule set must match (AND logic)
  2. Click Add Rule Set to add additional rule sets if needed — any rule set matching triggers the policy (OR logic)
  3. Click Save

Example audit policies:

Example 1 — Suppress service account logons:

This policy suppresses routine service account logon events to reduce forwarding volume.

Policy Name: Suppress Service Accounts

Action: DENY

Rule Set 1: Service Account Pattern

  Condition: TargetUserName EndsWith “$”

  Condition: EventID Equals “4624”

Rule Set 2: Specific Service Accounts

  Condition: TargetUserName Equals “NT AUTHORITYSYSTEM”

  Condition: EventID Equals “4624”

Example 2 — Forward privileged logon events:

This policy ensures privileged logon events containing specific privileges are always forwarded.

Policy Name: Alert Privileged Logons

Action: ALLOW

Rule Set 1: Admin Logon

  Condition: EventID Equals “4672”

  Condition: PrivilegeList Contains “SeDebugPrivilege”

Policy evaluation order:

Policies within a group are evaluated in the order they are listed. Consider the following when setting policy priority:

  • Place more specific DENY policies before broader ALLOW policies to ensure targeted suppression works as intended
  • Place critical ALLOW policies at a high priority to ensure important events are not inadvertently suppressed by a broader DENY policy
  • Test policies against real sample events before activating them in production

[Your administrator should document the intended logic and business rationale for each audit policy so other administrators can understand and maintain them correctly.]

Editing an existing audit policy:

  1. Navigate to the group’s Audit Policies configuration
  2. Locate the policy to edit
  3. Click the Edit icon
  4. Modify the policy name, action, rule sets, or conditions as needed
  5. Click Save

Enabling and disabling policies:

To temporarily suspend a policy without deleting it:

  1. Locate the policy in the Audit Policies list
  2. Toggle the Active switch to off
  3. The policy will not be evaluated until re-enabled

Deleting a policy:

Deleting a policy is permanent. Consider disabling the policy instead if you may need it again in the future.

  1. Locate the policy
  2. Click the Delete icon
  3. Confirm the deletion

Best practices:

  • Use descriptive policy names that clearly indicate what the policy does and why — this is especially important for DENY policies where the intent may not be obvious
  • Start with ALLOW policies focused on the events you want to collect before adding DENY policies to suppress noise
  • Use DENY policies carefully — an overly broad suppression policy can silently drop security-relevant events
  • Test new policies on a small non-production group before applying them to production machines
  • Review audit policies regularly to ensure they remain appropriate as your environment and security requirements evolve
  • Use the Regex operator for complex pattern matching where standard operators are insufficient
  • Document the business logic behind each policy, particularly DENY policies, so the team understands what is being suppressed and why

[Your administrator should audit active policies across all groups periodically to confirm that no critical event types are being inadvertently suppressed.]