HackBlue

Tools · SIEM and detection engineering · 16 / 24

Tuning noisy detections without creating blind spots

Reduce false positives with narrow, documented exclusions, avoid exclusions attackers can easily abuse, and measure tuning impact before and after.

10 min read · practice only with authorization

Tune with evidence

Start by grouping recent alerts by the fields that vary: parent process, user, host group, command-line pattern. Often a handful of benign sources cause most of the noise. Exclude those specifically, and keep the rest of the rule intact.

Snippet
index=notable rule_name="Suspicious Scheduled Task" earliest=-30d
| stats count by parent_process, user, host_category
| sort - count | head 15

Safe and unsafe exclusions

Good exclusions are narrow and hard to fake: a specific signed binary path plus its signer, a specific service account on a specific server group, or an exact command-line pattern from a management tool. Risky exclusions are broad or attacker-controlled: excluding by process name only (anyone can name a file setup.exe), excluding whole folders users can write to such as C:\Users\*\AppData, or excluding entire host groups.

Lab: tune a rule two ways

Take a rule that fires on schtasks.exe /create and look at 30 days of lab data. Write one exclusion by process name only and another by parent image path plus signer plus a command-line pattern for your management agent. For each, ask: could an attacker on a workstation trivially match this exclusion? Keep the narrow one, document why, and add an expiry or review date.

Snippet
detection:
  selection:
    Image|endswith: '\schtasks.exe'
    CommandLine|contains: '/create'
  filter_mgmt_agent:
    ParentImage: 'C:\Program Files\ExampleMgmt\agent.exe'
    CommandLine|contains: '/tn "ExampleMgmt\'
  condition: selection and not filter_mgmt_agent

Measure before and after

Replay the tuned rule over the same historical window and compare alert counts. Confirm any previous true positives still fire. Record the exclusion in the rule’s documentation with the owner and review date, and alert when an exclusion is used by an unexpected host.

Diagram

Risky versus narrow exclusion

Exclusions are attack surface.

Risky

Condition. Image endswith setup.exe

Can an attacker match it?. Yes, by renaming a file

Blind spot. Large

Narrow

Condition. Exact parent path, signer, and command-line pattern

Can an attacker match it?. Only by compromising the management agent

Blind spot. Small and documented

Check yourself

1. Why is excluding by process name alone risky?

2. Which exclusion is safest?

3. After tuning, how do you verify you did not break the rule?