🎯 New here? Make sure you check out the Intro, Part 1, Part 2 , Part 3, Part 4 and Part 5 before diving into this post. They lay the foundation you’ll need for what’s coming next.

Tuning False Positives: The Underrated Skill of Every SOC Analyst

By now, you’ve seen how powerful Detection & Response (D&R) rules can be. We’ve crafted detection logic, watched it fire on malicious activity, and even blocked threats before they could do real damage.

But there’s a crucial step that separates a good detection engineer from a great one: false positive tuning.

Why Tuning Matters

False positives are alerts triggered by legitimate activity that looks suspicious but isn’t actually malicious. Too many of these can drown out real threats, waste time, and erode trust in your detection system.

In a real SOC environment, if your rules cry wolf too often, your alerts will start getting ignored—and that’s exactly when something truly dangerous can slip by.

Real-World Example: Tuning Our “Volume Shadow Copy Deletion” Rule

Let’s revisit the D&R rule we created to detect and block this command:

vssadmin delete shadows /all

It’s an action often taken by ransomware—but in some environments, backup or disk management software might run similar commands during legitimate maintenance.

So how do we tune the rule to reduce false positives without losing our ability to detect real threats?

✅ Step-by-Step: Tuning in Action

1. Run the Rule in Alert-Only Mode First

Before blocking anything, configure the rule to just report activity:

- action: report
  name: shadow_copy_deletion_alert

2. Let It Run for a Week (or more)

Give your rule some time to collect data. During this period:

• Monitor alert frequency
• Check what processes are triggering the rule
• Identify patterns that appear harmless

3. Analyze the Telemetry

Imagine you find that a backup utility, say BackupService.exe, routinely runs this command during nightly operations.

4. Add an Exclusion Clause

Update your rule to ignore legitimate sources by refining the PROCESS_NAME or PARENT_PROCESS_PATH:

- op: is
  path: event/FILE_PATH
  value: C:\Windows\system32\vssadmin.exe
- op: contains
  path: event/COMMAND_LINE
  value: 'delete'
- op: contains
  path: event/COMMAND_LINE
  value: 'shadows'
- op: not
  rules:
    - op: contains
      path: event/PARENT_PROCESS_PATH
      value: 'C:\Program Files\BackupUtility\BackupService.exe'

Now, your rule still catches malicious use of vssadmin, but ignores the noise from known, trusted software.

Tip: Test and Retest

After tuning, run your test cases again:

• Execute the same Sliver payload or ransomware simulator.
• Confirm that malicious activity still triggers the rule, while legitimate software no longer does.

Final Thoughts

Tuning false positives is where detection engineering becomes more of an art than a science. It takes time, context, and domain knowledge—but it’s absolutely essential if you’re serious about building reliable, high-fidelity detections.

Here’s a quick checklist:

✅ Start with alert-only mode
✅ Let the rule run and gather data
✅ Analyze patterns and recurring benign events
✅ Update the rule with exclusions or refined logic
✅ Retest with known threats

keep experimenting and don’t be afraid to tweak your rules—every false positive you tune out is one step closer to elite detection engineering. 🛡️