Stop 07 · Security Operations & MonitoringTopics · 10/10

Building Detection Rules

In short

Threat intelligence and ATT&CK are only ideas until you turn them into a rule that fires. Detection engineering is writing those rules, then tuning them so they catch attacks without crying wolf.

Writing rules (in a SIEM or IDS) that trigger an alert on specific suspicious patterns — translating threat intelligence and ATT&CK techniques into actual, actionable detection logic.

The blob turns the sensitivity dial on a smoke alarm just right, toast nearby.

Think of it like this

Setting the right sensitivity on a smoke alarm

A smoke alarm set too sensitive screams every time you make toast, so people pull its battery out. Set too dull, it misses a real fire. Writing a detection rule is finding that middle setting, then adjusting as the kitchen changes.

Watch it happen

From idea to live rule

Idea

Write

Test

Tune

Deploy

1/5Start from a technique or incident: 'detect brute force on our VPN login'.

The big ideas

What you need to know

Sigma is portable

Sigma writes a rule once in YAML, then converts it to Splunk, ELK and more. Learn it early.

Test on real history

Run a new rule over past logs first. It shows both the attacks caught and the noise created.

Balance the two errors

Too tight misses attacks, too loose buries you. Good rules sit in the narrow useful middle.

Rules need upkeep

Systems change and a once good rule starts missing or over firing. Review your rules on a schedule.

See it in code

Walk through the code

yaml

1title: Many failed VPN logins from one source2logsource:3  product: vpn4  category: authentication5detection:6  failures:7    action: failure8  timeframe: 5m9  condition: failures | count() by src_ip > 1510falsepositives:11  - Backup service retrying with a stale password12level: medium

1/3logsource says which logs this rule reads, here VPN authentication events.

A Sigma rule in plain YAML. The falsepositives section is not decoration; it reminds the next analyst what is safe to ignore.

Save yourself the pain

Common mistakes

Oops

Shipping a rule straight to production untested.

Do this instead

Backtest over historical logs first. You will almost always find noise to trim before it ever goes live.

Oops

Writing a rule and forgetting it exists.

Do this instead

Review rules regularly. As the environment changes, yesterday's good rule starts missing attacks or spamming alerts.

Your mission

Write your first Sigma rule

~45 min

Quick check

Why should you backtest a new detection rule over historical logs before deploying it?

Go deeper

1Write a basic detection rule for a specific suspicious pattern (e.g. multiple failed logins).
2Learn to test a detection rule against both malicious and benign sample data to check for false positives.
3Understand why overly broad rules generate noise, and overly narrow ones miss real attacks.