Detection engineering is the discipline of building the alerts that a SOC responds to. It sits between offensive knowledge and defensive tooling, and it is one of the most in demand skills in defensive security.
The core idea is simple and often ignored: a detection should describe behavior, not a specific instance of it.
Indicators Versus Behavior
An indicator is a specific fact: this file hash, this IP address, this domain. Indicators are cheap to write and they expire almost immediately, because an attacker changes them for free.
A behavior is what the attacker had to do: a process spawning a command shell from a document application, credentials being read out of memory, a scheduled task created by a non administrative process, or authentication from a new country immediately followed by a mailbox rule creation.
The pyramid of pain, an idea from David Bianco, is the usual way this is explained. The higher up you write your detections, the more it costs the attacker to evade them. Hashes are trivial to change. Behavior is expensive.
The Anatomy of a Good Detection
A hypothesis, stated plainly. If an attacker does X, then Y will appear in Z data source.
A data source that genuinely contains the evidence. This is where most detections die, because the field you need is not being collected.
Logic that matches the behavior without matching everything else. Precision is the hard part.
A documented response. What should the analyst do when this fires, what does it usually mean, and what are the known benign causes. A rule without this is an incomplete piece of work.
An owner and a review date, because environments change and a rule that was precise last year may be noise now.
MITRE ATT&CK as the Organizing Map
Detection coverage is almost universally described against MITRE ATT&CK. It gives you a shared vocabulary and a way to see gaps.
The trap is treating coverage as a percentage to maximize. Techniques are not equally likely, equally damaging, or equally detectable in your specific environment. A heat map that is green everywhere usually means the rules are shallow, not that the organization is safe.
The better use is to pick the techniques that matter for your environment and your likely threats and go deep on those.
Sigma and Detection as Code
Every platform has its own query language, which historically made sharing detections painful. Sigma solves this with a vendor neutral YAML format that converts into platform specific queries.
The public SigmaHQ rule repository is a large, free, community maintained detection library and one of the best learning resources available. Read the rules, not just run them.
Detection as code means keeping rules in version control, reviewing changes, and testing before deployment, exactly like software. It sounds obvious and it is still not the norm.
Tuning Without Going Blind
Every new rule produces false positives. The response determines whether the program works.
The right move is to find out what the benign cause is and exclude that specific thing precisely. The wrong move, which is extremely common, is to broaden the exclusion until the alert stops firing, which usually excludes the attack too.
Track the false positive rate per rule and treat a persistently noisy rule as a defect with an owner and a deadline. A rule that nobody trusts is worse than no rule, because it consumes attention and provides false comfort.
Validation Is Not Optional
Writing a rule is a hypothesis. Until you have run the behavior and watched the rule fire, you have an untested hypothesis.
The free way to validate is Atomic Red Team, which provides small scripted tests mapped to ATT&CK techniques. The commercial way is a breach and attack simulation platform that does it continuously.
Validation regularly finds that a rule was never going to fire, because a field name differs, because the log source is not actually enabled on the systems that matter, or because the rule matched an artifact of the one sample it was written from.
How to Learn It
Read published detections and work out why each condition is there. Reproduce an attack technique in a lab, look at what it actually generated in the logs, and write the rule yourself.
Then attack your own rule and try to evade it, which teaches more than writing ten more rules. That loop is the entire content of Week 10 of the mentorship, described in purple team and attack simulation.
Learn This at HackRange
Detection engineering pays well and hires people who can prove they think in behavior. Building and validating your own detections is the proof.