A converted Sigma rule runs in your SIEM without error and matches nothing. Why?

### Why this is the characteristic failure of portable rules A rule that fails loudly gets fixed. A rule that converts cleanly, deploys cleanly and returns nothing looks exactly like a healthy detection over a quiet estate, and it can sit that way for a year. In a co-managed estate - a provider authoring detections in Sigma, the customer running the SIEM - it is the default outcome rather than an unlucky one, because neither party owns both ends of the mapping. ### The first discipline: silence proves nothing The absence of hits is compatible with at least four different worlds: the behaviour did not happen; it happened but the telemetry never arrived; it arrived in a table the query does not read; or it is in the table but in a column the query does not match. Only the first is good news, and it is the one you have the least evidence for. Treat a never-fired converted rule as unvalidated until you have made it fire deliberately. ### The diagnosis ladder, from the data upward **Is there data at all?** Query the table the pipeline chose, unfiltered, for one host and one hour. If it is empty, the problem is upstream of the rule - the logsource was resolved to the wrong table, or that data is not being collected from those hosts, or it lands somewhere else entirely. This is one query and it eliminates the largest class of causes. **Does the record you expect exist?** Find one raw event of the right kind by hand, without the rule. Look at the actual columns and the actual values. This is where most mapping bugs become visible in seconds. **Which clause kills it?** Take the generated query, strip it to its broadest single condition, confirm rows come back, then reintroduce clauses one at a time. The clause whose addition zeroes the result is your suspect. **Does the rule fire on a known-true event?** Execute the behaviour under controlled conditions on one instrumented host, in a window you have written down, and check each stage: the record arrived, the column holds what you expected, the query returns that record. A rule that will not fire on a deliberately produced true event is broken. This step is the only one that produces positive evidence, and it is the step people skip. ### The mapping failures that actually occur | Failure | What it looks like | | --- | --- | | Wrong table | Logsource resolved to a table that holds a different event class; query valid, always empty | | Name mapped, meaning not | Sigma `Image` is a full path; the target column holds only the leaf file name, so a path prefix match cannot succeed | | Column populated by a different sensor | The field exists in the schema but only rows from one agent carry it; hosts running the other agent are invisible | | Unparsed payload | The event arrives as a blob or nested structure and the columns the rule wants only exist after a parser or extraction step | | Case and escaping | The taxonomy defines case-insensitive matching; the backend operator chosen by the converter is case-sensitive, or a backslash or wildcard is escaped differently | | Value formatting | Paths, account names or hashes stored in a different form - short name versus domain-qualified, upper versus lower case hex | Notice that only the last two are properties of the conversion. The rest are properties of your environment, which is exactly why a rule can be simultaneously correct as published and useless as deployed. ### The fix goes in the pipeline, not the query It is tempting to edit the generated SPL or KQL until it matches, especially mid-incident, and as a stopgap that is fine. As the fix it is a trap: the edit lives in the SIEM, the next conversion of the same Sigma source will not contain it, and the two artefacts silently diverge. Push the correction into the processing pipeline instead - one mapping correction there fixes every rule that touches that field, which is the whole reason the pipeline exists as a separate thing from the rule. ### What you tell the person who asked Not "the rule is deployed". Either "the rule is deployed and I have seen it fire on a generated event", or "the rule is deployed and unvalidated, and here is what I still need to confirm". Those are different claims and only one of them is worth anything when someone asks whether you would have caught it.