The logging post on this trail ended with a promise: a SIEM correlates a billion log lines into the handful of alerts a human should see. This post is about the people who make that sentence true. Detection engineering is the discipline of writing, testing, and tuning the rules that decide what counts as suspicious — and it's one of the most interesting, most underexplained jobs in security.
A detection is a hypothesis
Every rule begins as a falsifiable claim: "if an attacker does X in our environment, it will appear in this log source looking like Y." Take a concrete one, courtesy of the ransomware post's stage 3: attackers dump credentials from memory by accessing a particular system process. Hypothesis: endpoint logs will show unusual processes requesting access to it. The rule encodes that pattern; the SIEM evaluates it against the stream; matches raise alerts. Written down like that it sounds mechanical. The craft is entirely in what comes next.
The real enemy: false positives
Here's the trade's central tension. Write the rule too narrowly and attackers who vary their technique slip past (a false negative — invisible, and you may learn about it from a ransom note). Write it too broadly and it fires on legitimate activity — backup agents, monitoring tools, and antivirus touch that same system process constantly. A rule that cries wolf fifty times a day doesn't just waste time; it trains humans to ignore it, which is functionally worse than no rule at all. This failure mode has a name — alert fatigue — and it has featured in the post-mortems of famous real breaches where the alert fired and nobody looked. Tuning — adding exclusions for known-good noise without excluding the attack — is therefore not cleanup after the real work. It is the real work.
How the discipline professionalised
- A shared map: the MITRE ATT&CK framework catalogues real-world attacker techniques, giving teams a language for coverage — "we detect these twelve techniques from the ransomware chain; these four are blind spots" — and turning gut feeling into a heat map.
- Detection as code: mature teams keep rules in version control like software — peer-reviewed, tested, deployed through pipelines, documented with the hypothesis and its known exclusions. A detection nobody can explain is a detection nobody can safely tune.
- Adversarial testing: you validate a detection the honest way — by safely simulating the attack and confirming the alert fires. Red teams and purple-team exercises exist substantially to test hypotheses like these; a rule that has never been triggered on purpose is a smoke alarm nobody's ever pressed the test button on.
Notice what this discipline reveals about the whole field: detection isn't a product you buy — the SIEM is an engine, and detections are content, specific to your environment's shape and noise. Two organisations with identical tools can have wildly different real-world visibility. When vendors advertise "thousands of built-in detections," the practitioner's question is the one you can now ask: tuned to whose normal?
If this post clicked, you've effectively toured a career: SOC analysts triage the alerts, detection engineers write and tune them, threat hunters chase the hypotheses no rule covers yet. All three start exactly where this trail started — with someone reading logs until normal became recognisable, and abnormal became visible.