Writing detections
A detection turns a hunch into a rule that runs every minute without you. This lesson shows how to go from "an attacker would do X and it would look like Y in our logs" to a portable rule in Sigma, mapped to MITRE ATT&CK, tuned for a low false-positive rate and shipped as code with tests, so the next analyst trusts it and the attacker cannot shrug it off.
By the end you can
- Turn an attack hypothesis into a detection and pick the right type for it
- Run the detection engineering loop: hypothesis, data check, write, test, tune, deploy, review
- Write a portable rule in Sigma with a logsource, a detection and a condition
- Map every rule to a MITRE ATT&CK technique so you can measure coverage
- Trade precision against recall on purpose, and keep rules as code with metadata and test cases
The everyday picture
Think of a quality inspector on one of Mangrove's packing lines. Early on, she catches bad boxes by eye. That works until she is off sick, and nobody else sees what she saw. So she writes it down: "if the seal is torn, or the weight is under 480 grams, pull the box." Now a new starter catches the same faults on her day off. The written rule does the watching; she spends her time finding the next kind of fault.
A detection is that written rule for an attack. In Logs that matter you learned which logs to collect and how to query them fast. A detection takes one clear idea about an attacker, "they would try one password against hundreds of accounts, and our auth log would show many failures from one address", and turns it into a rule the system runs every minute, so you are not the only pair of eyes. The rest of this lesson is how to write that rule well: so it fires on the real thing, stays quiet the rest of the time, and any analyst can read it and improve it.
From hypothesis to detection, and the four types
Every good detection starts as a sentence: an attacker would do X, and it would look like Y in these logs. The X comes from how attacks really work (How breaches really happen) and from MITRE ATT&CK, a public catalogue of attacker techniques. The Y is the concrete pattern in a log you actually collect. If you cannot name the log and the fields, you do not have a detection yet; you have a wish.
Once you have the pattern, pick the kind of rule that fits it. There are four common types, and choosing the wrong one is the most common beginner mistake.
- Signature or IOC. Match an exact value: a known-bad file hash, a malicious domain, an attacker's IP address. A indicator of compromise (IOC) is cheap to write and precise, but it only catches that one value. Change the file by one byte and the hash is new.
- Threshold. Count events over a time window and fire when the count crosses a line: more than twenty failed logins from one source in five minutes. Good for brute force, scanning and floods.
- Anomaly or behavioural. Fire when something departs from a baseline: a store account that always logs in from one city suddenly signs in from another at 2 a.m. Powerful, but it needs a baseline and it is noisier.
- Correlation. Join signals across sources: a risky login (identity log) followed by a new admin account (back-office log) within ten minutes. Harder to write, but it describes a whole attack step, not a single event.
A signature says "this exact thing is bad". The other three say "this pattern of behaviour is suspicious". That difference matters later, when we ask how much a detection actually costs the attacker.
Quick check
You want to catch an attacker who signs in with a valid but stolen Mangrove staff password from a country where that person has never worked. Which detection type fits best?
The login succeeds with a real password, so there are no failures to count and no bad file to hash. What stands out is the departure from the account's normal pattern, which is exactly what an anomaly or behavioural rule measures. Last month's IP will not be reused, so a signature on it catches nothing.