How can an asset-owner lookup inside a scheduled SIEM detection create a blind spot?

## Enrichment is not correlation, and it is not a filter A lookup attaches attributes from a static or scheduled table — an asset inventory, a service-account-to-owning-team map, an HR feed — to events that already matched the detection. Its job is to make an alert triageable: which team owns this database, is this service account still in use, who is the human behind it. In a managed cloud database estate where the audit stream is the SOC's only view, that mapping is the difference between *some service account read the customer table* and *the shared application service account owned by the payments team, used from a contractor's workstation, read the customer table*. The mistake is letting the enrichment decide **which events are eligible to alert**. ## The mechanics that produce the blind spot In SPL, `lookup my_assets.csv database OUTPUT owner_team` keeps every event. Where the key does not match, `owner_team` is simply unset. That is safe on its own. It stops being safe when: - a later command filters on the enriched field, for example `| where owner_team!="sandbox"` or `| search owner_team=*`, which discards every unmatched event as a side effect; - the enrichment is written as `join type=inner` against a search over an inventory index, which drops non-matching rows by definition; - in Kusto, the author uses `join` — whose default flavour is `innerunique` — rather than the `lookup` operator or an explicit `kind=leftouter`. In each case the rule's population silently becomes *assets present in the table* rather than *assets in the estate*. And the failure is invisible from the outside: the rule keeps alerting on the known estate, its runtime and alert volume look normal, and no error is ever raised. ## Why this failure mode is adversary-relevant rather than merely untidy The assets missing from the inventory are not a random sample. They are the recently created, the temporarily provisioned, the shadow project, the restored snapshot someone stood up to debug a support case and left running with a copy of production data. That population is systematically more attractive to an intruder and systematically less covered by everything else — patching, ownership, access review — for the same reason it is missing from the lookup. So the enrichment does not just lose coverage; it loses it precisely where the risk concentrates. The direction of the claim also matters. An empty `owner_team` is a statement about your inventory, not about the asset. It does not mean the database is unimportant, untouched, or out of scope. It means nobody wrote it down. ## Building it so the blind spot cannot open **Keep enrichment additive.** Detection logic filters on event fields; the lookup only adds context after the decision to alert has been made. **Give unmatched keys a value.** `| fillnull value="UNREGISTERED" owner_team` — or a default match configured on the lookup definition — so the field is never empty and no downstream comparison can quietly drop the row. **Make the unregistered bucket somebody's work.** Those events are not a detection backlog; they are a coverage backlog. Send them to a periodic report for the team that owns the asset inventory, and keep the detection alerting on the behaviour regardless of whether ownership is known. An alert that says *unregistered database, unknown owner, bulk read of a customer table* is more urgent than the same alert with an owner, not less. **Measure the match rate.** For each run, record the share of events that matched a lookup row. A slow decline means the inventory is falling behind the estate; a sudden drop usually means the feed that builds the table broke, or its key format changed — a hostname that gained a domain suffix, a resource identifier that gained a region prefix — which silently zeroes the match rate while the file still looks populated. **Watch freshness in both directions.** A stale table also holds rows that are wrong rather than missing: a decommissioned owning team, a rotated service account name. That routes real alerts to nobody, which is a different failure with the same root cause. ## Testing it The test that catches all of this is one fixture: an event whose key is deliberately absent from the lookup. If the rule still fires on it, the enrichment is additive. If it does not, the enrichment is a filter, and you have just found the population your detection cannot see.