Before writing a detection rule, what must be true of your telemetry for an adversary behaviour to be detectable?
answer
- a rule only sees collected fields
- separation, not volume
- compare malicious against the legitimate version
- one field's values must differ
- no separator means no rule is possible
basics
~20 sA record the estate actually writes must carry at least one field whose value differs between the behaviour and the same action done legitimately. With no separating field, no rule can match it, however the rule is written.
solid answer
~50 sDetection is a separation problem, not a logging problem. Three things must hold: the estate emits a record when the behaviour happens, that record is collected and reaches the SIEM, and it carries at least one field whose value distinguishes the behaviour from legitimate work. The third is where most candidate detections die. Windows Security 4769 is written for every Kerberos service-ticket request in the domain, so "a service ticket was requested" separates nothing — you need something narrower inside the record, such as which account the ticket was for and which account asked. Partial separation is fine and normal; you accept a false-positive rate an analyst can work. What is not fine is a rule built on a field whose values are identical for benign and malicious use, because it either never fires or fires on everything. If nothing separates, the honest output is a written statement that the behaviour is undetectable on the sensors you have.
go deeper
Be ready to state the three conditions in order — a record is written, it is collected, and one of its fields differs between malicious and legitimate use — and to give one example of a record that exists everywhere and therefore separates nothing.
An interviewer expects you to reason about base rates: name a field, say what its values look like during normal work, and say what they look like during the behaviour. Explain why the same field can separate in one estate and not in another.
Show that you walk the separation argument before proposing a rule, and that you can say out loud when nothing separates instead of shipping something that cannot fire. Be able to defend a partially separating field with a false-positive budget you can work.
Own the consequence for the programme: a rule that cannot match reads as coverage forever. Be ready to say how you judge a proposed telemetry investment by the specific behaviour and field it would separate, rather than by volume onboarded.
## What "detectable" actually means A detection is a predicate over records. It can only read fields that exist, in records that were written and collected. So before any rule is drafted, walk three conditions in order — and stop at the first that fails. **1. Does the estate emit a record at all when the behaviour happens?** Some behaviours produce nothing on the sensors deployed. An adversary requesting a Kerberos service ticket from a Linux host running an off-the-shelf toolkit runs no process on any monitored Windows endpoint, so there is no process-creation record to read anywhere on the endpoint side. Something is still written — the domain controller records the ticket request — but that is a different surface entirely, and reasoning about the wrong one is the classic beginner's error. **2. Is that record collected?** The host may write it while nobody ships it. This condition is real but it is an ownership question about telemetry pipelines rather than a detection-design question, and it is the one people jump to because it feels actionable. **3. Does the record carry a field that separates?** This is the condition that decides whether a rule is possible. "We have the log" is not the same as "the log distinguishes". Windows Security 4769 ("A Kerberos service ticket was requested") is written on a domain controller thousands of times an hour in a normal enterprise, because every domain-joined workstation asks for service tickets constantly to reach file shares and services. The existence of the record carries no information. The fields inside it might: which service account the ticket was issued for, which client account asked, how many distinct service accounts one client asked about in an hour, which encryption type the ticket was issued under. ## Separation is a property of the pair, not of the record The useful mental move is to write down the malicious case and the benign case side by side and ask which field's value differs. If the answer is "none", the record is not evidence, no matter how rich it looks. This is why two estates can have identical logging and different detectability: in a forest where every service account holds AES keys, an RC4-encrypted service ticket is anomalous and the encryption-type field separates; in a legacy forest whose service accounts were never re-keyed, RC4 is what the KDC issues all day and the same field separates nothing. The field did not change. The base rate did. ## Partial separation is the normal outcome Almost no field separates perfectly. Real detection engineering is choosing a field whose *distribution* differs enough that the resulting alert volume is workable, then narrowing with a second condition when it is not. A rule that fires forty times a day where thirty-eight are benign is a tuning problem. A rule built on a field with identical values on both sides is not a tuning problem — it is unbuildable, and no threshold rescues it. ## What each artefact actually proves Keep the direction of every claim straight, because this is where junior answers go wrong: - A record proves an **event was written**, not that a person did something. - A successful authentication record proves a **credential was accepted**, not that the owner was present. - A flow record proves **bytes moved**, not what they were — it carries a five-tuple, counts and timestamps and no payload. - An alert proves a **rule fired**, not that anything malicious happened. - The **absence** of an alert proves nothing about the estate at all: it is equally consistent with a quiet week, a rule that cannot match, and a source that stopped reporting. ## The honest ending Sometimes you finish the walk and there is no separating field. The professional output then is not a weak rule. It is a written statement naming the behaviour, the candidate records you examined, why each one fails to separate, and the specific change — a different sensor, a configuration that adds a field, an estate change that alters the base rate — that would make it detectable. A rule that cannot match is worse than no rule, because it looks like coverage on every subsequent review and stops anyone asking the question again. More logging does not automatically buy more detection. A new source helps only if it carries a field that separates a behaviour you care about from the normal work that resembles it. Otherwise it buys volume, cost and the comfortable feeling of visibility.
- Engineers often say "we have the log for that" and stop. Why isn't having the log enough?Because the record can exist for both the malicious and the benign version with the same field values. Windows Security 4769 is written for every Kerberos service-ticket request in the domain, so its presence separates nothing. Having the log is condition one; a field whose values differ between the two cases is the condition that decides whether a rule is possible at all.
- If a field separates the two cases only most of the time, is the detection worthless?No — partial separation is the normal case. You choose a field whose distribution differs enough that the alert volume is workable, then add a second condition if it isn't. That is a tuning problem with a false-positive budget. A field whose values are identical on both sides is a different thing: no threshold or correlation window rescues it.
- Does onboarding more log sources make more behaviours detectable?Only if the new source carries a field that separates a behaviour you care about from the normal activity that looks like it. Otherwise you have bought volume, storage cost and a feeling of visibility. Judge a proposed source by naming, in advance, the specific behaviour it would separate and the field that does the separating.
Two identical twins in identical uniforms walk past a security camera. The camera works perfectly and the footage is useless, because nothing in the frame differs between them. That is a record with no separating field.
saying these in an interview costs you the question
- Assumes having the log means the behaviour is detectable
- Treats the presence of a record as evidence of malice
- Believes more log sources automatically means more detection
- Thinks a threshold can rescue a field with identical values on both sides
- Reads no alerts as proof the behaviour is not happening