SIEM & Detection Engineering

An unbounded search can be finalized or truncated before it reads everything, so an empty result proves only that the search stopped early, not that nothing happened. Pin the index and the time range in the base search.

Only that this value never appeared in the rule's lookback window for that entity. It is a claim about your recorded history, not evidence that the value is malicious or even genuinely new.

A 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.

A rule only works if the records it queries exist and carry those fields. Declaring the source and field names makes that assumption checkable before deployment; a rule over missing data returns nothing and looks exactly like a quiet estate.

An indicator rule matches a fixed artefact such as a domain or hash, so it is cheap to write and dies when that artefact changes. A behavioural rule matches how the activity looks: costlier to tune, but it survives.

It claims what adversary behaviour the rule was written to catch. The label sits on the rule, not on any alert: a firing is not proof of malice, and the tag does not mean every variant of that behaviour is caught.

Sigma is a YAML format that describes a detection - a log source, field matches and a condition - independently of any product. It runs only after a converter and a field-mapping pipeline compile it into SPL, KQL or another backend query.

Nothing on its own. Zero alerts has at least three causes: there was no such activity, the rule is broken or muted by a pipeline change, or the data never reached the rule. Silence is a question, not an assurance.

Allowlisting a host silences every future firing of that rule there, including a real intrusion. Narrowing the logic removes only the benign pattern, and it removes it everywhere, so the rest of the estate keeps its coverage.

A single global threshold has to sit above the loudest legitimate account, so it sits far above a typical one. A user going from six downloads a day to forty has tripled and is still nowhere near the number. Comparing each account to its own history is what makes the change visible.

Usually the mapping, not the logic: the query was pointed at the wrong table, or a Sigma field was mapped onto a column that exists but carries something else - a bare file name where the rule expects a full path.

It becomes scoped and repeatable: pinned index and sourcetype, a window matched to the run interval with a lookback for late data, no wildcards or subsearch joins, and a fixed threshold. The narrowing is deliberate and written down.

Add a grace period: hold each window open, or delay evaluating it, until the slow feed has landed, and match on event timestamps. That buys correctness with detection latency and state held longer. Do not widen the correlation window instead.

Because join runs a subsearch that is capped and truncated without an error, so the correlation can silently omit the account you are hunting. Reading both sources in one search and aggregating with stats by the shared key is complete.

The domain controller's Kerberos ticket-issuance records: the only surface every requester in the forest must pass through. The cost is a thin vocabulary — no process, binary or parent at alert time — and an enormous benign base rate.

The watch must be loaded into the running kernel ruleset, not just present as a file; the audit daemon running and collected; the rule unshadowed by earlier rules; and the fields the detection reads arriving with those names.

Label at the granularity the logic can actually separate. A sub-technique ID claims the rule distinguishes that procedure from its siblings. If the rule fires identically on all of them, the parent is the honest label; if it only ever catches one, the parent hides that.

Detection backends treat an unknown field as absent, so a predicate on it is simply false, not invalid. The search still runs, still reports success, and returns an empty result set - a legal answer, not a fault.

An exclusion suppresses matches silently. Enforce it in the rule's logic rather than at the sensor, so the records still reach the log store, and record its scope and start date so you can search that gap later.

Confirm the flood is the migration by checking that the novel values are all the same expected new tenant on the change window, then suppress narrowly on that value with an expiry, keep every other detection live, and fix the cause with a cold-start learning period before any first-seen rule may fire for an entity.

Only one thing is forced: a domain controller must issue a service ticket for the targeted service account, recorded as a 4769. The encryption type, the tool, the source host and the request rate are all the adversary's choice, so detections built on them are optional to evade.

From evidence in received telemetry, not from desired state. Query recent records carrying the watch's tag per host, join that against the asset inventory for the uncovered remainder, and scope the rule's claimed coverage to the proven hosts.

That its clause still fires when the fixed artefacts are deliberately changed. Re-run the behaviour with a fresh hostname, certificate and TLS stack; replaying the stored record proves nothing, because it carries the artefacts you already know.

Only the container administration one, T1609. The API audit record proves a command channel was opened into a container. It shows no break-out to the node, so T1611 is a hypothesis, and every exec in the estate uses an accepted credential, so T1078 is true of everything and therefore says nothing.

Ship the selection without the threshold, scoped narrowly and routed to an investigation queue rather than the pager, and record what was dropped at deploy time. You have traded precision for coverage deliberately, which is defensible; doing it silently is not.

Date the data, not the story: plot the daily count of events populating the field the rule filters on, find the step change, and correlate it with the parser deploy record. Bound the claim to what retention supports.

The exclusion keyed on attacker-controllable attributes — any file can take that name and sit in that directory. Scope exceptions on code signature and parent chain, and alert whenever the excluded name appears without them.

Take the feed as enrichment on records and alerts by default, and let only a small, high-confidence subset alert, with an expiry date and a named owner who re-confirms it. The constraint is your analyst's week.

The baseline window never contained a quarter-end, so the rule encoded four ordinary weeks as the definition of normal. A threshold derived from a period is only valid for periods that look like it.