Five names for one field: how schema sprawl erodes detection coverage

A rule that never fires is not a rule that is working

Picture a lateral-movement rule that watches for a workstation opening administrative shares on more than ten peers in an hour. It keys on a field called src_host. The rule was written against domain controller logs and it works.

Six months later the endpoint agent is upgraded. Its events now carry the host name under device.hostname. The rule still parses, still runs, still shows a healthy zero in the alert count. It has simply stopped seeing half the environment.

No error was raised because nothing failed. A field went missing from the perspective of one rule, and the platform has no concept of "a rule that depends on a field that stopped arriving."

How sprawl accumulates

Schema sprawl is not a single event. It is the sum of many small, reasonable decisions.

• Vendors name fields for their own product. A firewall vendor, a cloud provider, and an identity platform each have a defensible reason to call the same concept something different.
• Onboarding is decentralized. Sources are added by whichever team owns them, each writing extraction logic that suits their tool. Nobody is responsible for the field names across all of them.
• Detections outlive the schema they were written for. A rule from three years ago encodes assumptions about the data that were true three years ago.
• Search-time extraction hides the problem. When field mapping happens inside the analytics tool at query time, every other consumer of the data still sees the raw mess.

Fix it once, upstream

The durable fix is to give the data one shape before any tool receives it. That means normalization happens in the pipeline, not in the SIEM, and every destination benefits.

Three capabilities make this hold over time:

1. A canonical dictionary. One agreed name for each concept. Public schemas such as OCSF or ECS are good starting points; the important thing is that there is exactly one.
2. Presence monitoring per source. The pipeline tracks which fields each source emits and how often. A field that appeared in 99 percent of events yesterday and 40 percent today is a signal, not a statistic.
3. Dependency awareness. The pipeline knows which canonical fields your live detections read. When one of them goes quiet for a source, that is treated as an outage.

A one-afternoon audit

• Export your top fifty detection rules and list every field each one reads.
• For each active log source, check whether it currently populates those fields under the canonical name.
• Every empty cell in that matrix is a source your rules cannot see.

Most teams that run this exercise find gaps they did not know about. The point of CyberAIX Pipeline is that the matrix stays full without anyone having to run the exercise by hand again.