SOC Operations In progress
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
Hypothesisbehavior -> log signature
Testatomic action in your lab
Ruleencoded + tested (Sigma style)
Deployto SIEM queues with risk tags
Tunefalse-positive feedback loop
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
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