Tuning & False Positives

The Tuning Imperative

You deployed a Sigma rule to your SIEM. It fires. A lot. 200 times a day. Every alert looks like this:

ALERT: Suspicious Scheduled Task Creation
Host: SRV-DEPLOY-01
User: svc_deployment
Image: C:\Windows\System32\schtasks.exe
CommandLine: schtasks /create /tn "AppDeploy_2026_Q1" /tr "C:\Deploy\run.bat" /sc daily /st 02:00

Is this malicious? No. It is the deployment team's automation creating scheduled tasks for software rollouts. But your rule fires on every single one because schtasks.exe /create matches the detection logic perfectly.

This rule is now useless. Not because the detection logic is wrong — it correctly identifies scheduled task creation. The problem is that it cannot distinguish between the deployment team's legitimate use and an attacker's malicious use. After a few days of 200 alerts, your analysts start ignoring it entirely. And the day an attacker actually uses schtasks.exe for persistence, the alert gets buried.

This is alert fatigue, and it is the number one killer of SOC effectiveness. Tuning is how you fix it.

Understanding Alert Categories

Before tuning, you need a framework for categorizing what your rule catches:

Click to enlarge

The Five Tuning Techniques

Technique 1: Field Narrowing

Make your selections more specific by matching on additional fields or using more precise modifiers.

Before (broad):

detection:
    selection:
        Image|endswith: '\\schtasks.exe'
        CommandLine|contains: '/create'
    condition: selection

After (narrow):

detection:
    selection:
        Image|endswith: '\\schtasks.exe'
        CommandLine|contains: '/create'
    selection_suspicious:
        CommandLine|contains:
            - '/sc onlogon'
            - '/sc onstart'
            - 'cmd.exe'
            - 'powershell'
            - 'http://'
            - 'https://'
            - '\\AppData\\'
            - '\\Temp\\'
    condition: selection and selection_suspicious

Now the rule only fires when the scheduled task creation includes suspicious indicators — persistence triggers, command interpreters, URLs, or unusual paths.

Technique 2: Value Exclusion Lists

Add a filter section that explicitly excludes known-good values:

detection:
    selection:
        Image|endswith: '\\schtasks.exe'
        CommandLine|contains: '/create'
    filter_deployment:
        User:
            - 'svc_deployment'
            - 'svc_sccm'
            - 'SYSTEM'
        CommandLine|contains:
            - 'AppDeploy_'
            - 'WindowsUpdate'
            - 'GoogleUpdate'
    condition: selection and not filter_deployment

This filter removes alerts from known deployment accounts and recognized task names.

Technique 3: Path-Based Filtering

Legitimate software runs from predictable paths. Attackers stage tools in unusual locations:

detection:
    selection:
        Image|endswith: '\\schtasks.exe'
        CommandLine|contains: '/create'
    filter_legitimate_paths:
        CommandLine|contains:
            - 'C:\\Program Files\\'
            - 'C:\\Program Files (x86)\\'
            - 'C:\\Windows\\System32\\'
    condition: selection and not filter_legitimate_paths

Tasks created with executables in standard paths are filtered out, focusing the rule on tasks referencing unusual locations.

Technique 4: User and Account Filtering

Different users carry different risk levels:

detection:
    selection:
        EventID: 4625
    filter_service_accounts:
        TargetUserName:
            - 'svc_monitoring'
            - 'svc_backup'
            - 'healthcheck'
    filter_machine_accounts:
        TargetUserName|endswith: '$'
    condition: selection and not filter_service_accounts and not filter_machine_accounts

Known service accounts and machine accounts are excluded from brute force detection because their authentication failures are expected.

Technique 5: Time-Based Suppression

Some legitimate activity happens on predictable schedules:

# Configure in SIEM post-conversion:
# Suppress rule between 01:00-03:00 daily (maintenance window)
# Suppress on first Saturday of month (patch weekend)

The Tuning Workflow

When a rule is generating too many alerts, follow this systematic process:

Step 1: Collect a Sample

Pull the last 24-48 hours of alerts from the noisy rule. Export them for analysis.

Step 2: Categorize Each Alert

For each alert, mark it as TP (real attack), FP (wrong match), or BTP (correct match, legitimate activity).

Step 3: Identify Patterns in BTPs

Look for commonalities across the benign true positives:

Step 4: Write Filters

Create Sigma filter sections that match the BTP patterns without excluding real attacks.

Step 5: Test the Tuned Rule

Re-evaluate the alert set with the new filters. Verify:

• All BTPs are now excluded
• No real TPs are accidentally filtered
• The remaining alerts are actionable

Step 6: Deploy and Monitor

Deploy the tuned rule and monitor alert volume for 48 hours. If new BTPs appear, repeat the process.

Click to enlarge

Tuning Anti-Patterns

A Real-World Tuning Example

Here is a rule before and after tuning, with metrics:

Before tuning:

title: Scheduled Task Creation
detection:
    selection:
        EventID: 7045
        ServiceType: 'user mode service'
    condition: selection
level: medium

Alerts per day: 187 (3 TPs, 12 FPs, 172 BTPs)

After tuning:

title: Suspicious Scheduled Task Creation — Tuned
detection:
    selection:
        EventID: 7045
        ServiceType: 'user mode service'
    filter_known_software:
        ServiceName:
            - 'GoogleChromeElevationService'
            - 'MozillaMaintenance'
            - 'AdobeUpdateService'
            - 'MicrosoftEdgeUpdate'
    filter_standard_paths:
        ImagePath|startswith:
            - 'C:\\Program Files\\'
            - 'C:\\Program Files (x86)\\'
            - 'C:\\Windows\\'
    filter_deployment:
        ImagePath|contains: '\\Deploy\\'
        AccountName: 'svc_deployment'
    condition: selection and not filter_known_software and not filter_standard_paths and not filter_deployment
level: medium

Alerts per day: 4 (3 TPs, 1 BTP) — 97.8% noise reduction

Key Takeaways

• Tuning is not optional — an untuned rule causes alert fatigue and is worse than no rule at all
• Benign True Positives (BTPs) are the primary target of tuning: the rule is technically correct, but the activity is legitimate
• The five tuning techniques are: field narrowing, value exclusion lists, path-based filtering, user/account filtering, and time-based suppression
• Follow a systematic workflow: collect → categorize → find patterns → write filters → test → deploy → monitor
• Never filter too broadly — use exact values, not wide patterns that could accidentally exclude real attacks
• Document every filter in the Sigma rule's falsepositives section and as comments in the filter
• Schedule quarterly tuning reviews because environments change: new software, new accounts, new paths

What's Next

You know how to write, convert, deploy, and tune Sigma rules. In Lesson 8.6, you will explore the SigmaHQ repository — 3,000+ community-contributed rules covering every major ATT&CK technique. You will learn to navigate the repository, evaluate rule quality, select high-value rules for your environment, and batch-deploy them. Lab 8.6 has you pick 10 rules, convert them all, and verify they are active in Wazuh.