Why does a detection rule declare the log source and fields it needs, not just the search?

## The rule is not just the logic Most people first meet a detection rule as its search: a condition over some records. That is only half of it. The other half is a set of assumptions about the world, and those assumptions are what actually decide whether the rule ever produces an alert: 1. **A source exists and is shipping.** Some agent, forwarder or platform is emitting records of the right kind, from the hosts you care about, into the store the rule runs over. 2. **The records carry the fields.** The logic reads named fields. Those fields must be present and populated for *this* source, not merely defined in the schema. 3. **A host-side prerequisite is satisfied.** Many sources emit nothing about a behaviour unless something was deliberately enabled: an audit rule loaded into the kernel, a configuration section that turns on a particular event class, an audit policy subcategory switched on. The telemetry does not exist by default. A rule that names all three is a *contract*. A rule that names none of them is a guess that looks like a control. ## Why the failure mode is so dangerous Detection has an asymmetry that most engineering does not. When a web service is broken it returns errors; when a detection is broken it returns **silence**, and silence is exactly what a healthy detection produces most of the time. There is no error to page on. A rule pointed at a field nobody populates, or at hosts where the required audit configuration was never applied, will sit in the console at zero hits looking precisely like a rule doing its job in a clean estate. So the direction of inference matters: **a rule producing no alerts tells you nothing about the estate.** It could mean the behaviour did not occur, or that the records never arrived, or that they arrived with different field names, or that the logic never matched. Declaring the inputs is what lets you rule out the boring explanations before you start believing the interesting one. ## What a declaration looks like in practice Take persistence by writing an attacker-controlled SSH public key into a service account's `authorized_keys` on a Linux server fleet. There is no EDR on the older half of that fleet, so the observation surface is the Linux audit subsystem. A rule for this behaviour should state: - **Source:** Linux audit records from hosts in the server fleet, shipped by the log agent. - **Prerequisite:** a file watch covering the `.ssh` directories, loaded into the running kernel audit ruleset and tagged with a known key, plus the audit daemon running and its output being collected. - **Fields read:** the file path written to, the executing process image, and the acting user identity - in ECS terms `file.path`, `process.executable` and `user.effective.id`. - **Scope:** which hosts this is asserted to be true for. Each line is falsifiable. You can query the last few days of received records for that watch key per host and see which hosts have ever produced one. You can check whether the field the logic reads is populated on real records rather than merely legal in the schema. Neither check requires an adversary to cooperate. ## Schema presence is not population A common junior error is to treat a shared schema - Elastic Common Schema, OCSF - as a guarantee. It is not. A schema defines what a field is *called* and what it *means*; it says nothing about whether any particular source fills it in. Cloud audit records, endpoint process records and file-integrity records all live in the same schema and populate wildly different subsets of it. Writing `process.executable` into your logic is a bet that the source you picked actually carries the executing process, and plenty of file-oriented sources do not. ## What this buys you Declaring inputs is what makes three later things possible: deploying a rule only where its prerequisite is proven, stating detection coverage as a host set rather than a hope, and reviewing the rule when the platform changes underneath it. It is also the cheapest honesty available in detection engineering - it costs a few lines of metadata and it removes the single most common way a detection is wrong, which is that it was never able to fire in the first place.