SOC Operations
Advanced 20 min read SOC Operations

Detection Engineering

Write detections like code: hypotheses, atomic tests, false-positive budgets, and the unit-test-for-alerts pipeline that keeps the queue honest.

Sigmadetectionfalse positivesatomic testtuningrule lifecycle
Introduction

What is this?

Detection engineering is the practice of turning attack behaviors into testable, tunable, maintainable alert rules with a feedback loop back to the threat model.

Motivation

Why do you need it?

  • A detection without a test is a wish; engineering rigor makes alerts reproducible evidence, not vibes.
  • Sigma and attack patterns make rules portable across the SIEMs different teams inherit.
  • The false-positive budget is the currency of SOC trust — engineering pays analysts back in clean queues.
Think about it

Mental model

Imagine

A smoke detector installation

Think of

A fire-alarm system with a smoke test scheduled every month

The alarm is only trustworthy if you check monthly that it still fires on smoke and stops on reset.

Mechanics

How it works

  • Each detection starts from a hypothesis: 'this attack does X, which shows up in logs as Y'.
  • Atomic tests (real actions on your own lab) generate the log signature; you encode it as a rule.
  • The rule ships with metadata: severity, ATT&CK ID, false-positive profile, and a test that passes.
  • Feedback: alerts cycle back — false positives tune the rule, new behavior extends it.

The detection lifecycle

Hypothesis
Test
Rule
Deploy
Tune
Real world

In production

  • A bank turns a tabloid detection into a Sigma rule with two atomic tests and watches the queue stay clean for a month.
  • A team writes a 'new user + first token' rule after an Intune misconfig and catches the reoccurrence in a week.
  • A small SOC uses a playbook that re-tests every rule each quarter against a changing estate.
Guidelines

Best practices

  • One rule per behavior, with a name, ATT&CK mapping, and an owner.
  • Test on your own data before shipping: the atomic action must fire your rule.
  • Track false-positive rate per rule; retirement of a broken rule is engineering too.
  • Version rule changes and tie them to the incident that motivated them.
Watch out

Common mistakes

  • Writing rules from documentation alone and never validating they fire on real telemetry.
  • Every new alert 'urgent, critical' until nothing is critical anymore.
  • Never tuning: the rule fires 500 times, the team works around it, and the alert dies of neglect.
  • Detecting artifacts (hashes) instead of behaviors that survive the attacker's next variation.
When things break

Debugging tips

  • If a rule doesn't fire, load the atomic test's actual logs and diff the field values against the rule's selector.
  • Track a rule's alert counts over a week; spikes are either incident or tuning opportunity.
  • Use a scratch SIEM dashboard per rule to see the full event detail behind a hit.
Security

Security considerations

  • Atomic tests belong in labs you own; never fire attack actions against production or third-party systems.
  • Rules encode knowledge of attack techniques — that knowledge is the same power a defense must steward carefully.
Interviews

Interview checkpoint

Practice

Hands-on lab

Write, Test, and Tune a Detection on Your Own Logs
50 min · advanced
In progress
Objectives
  • Generate a synthetic 'suspicious' event in your lab.
  • Encode a Sigma-style YAML detection.
  • Use a simple matching script to prove the rule fires, then tune its scope.

Write, Test, and Tune a Detection on Your Own Logs

50 min · advanced

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

The right way to validate a detection rule is...

2

Sigma primarily helps you...

Go deeper

Official documentation