Why the same field has three names
One log calls it src_ip, another source.ip, a third clientIP. Detection logic written against raw field names breaks the first time a log source changes.
A firewall calls it src_ip. A cloud audit log calls it sourceIPAddress. An
EDR calls it source.ip. All three mean the address the connection came from.
Normalisation is the work of mapping those onto one agreed name before anything queries them. Schemas like ECS and OCSF exist to provide that agreed name so you are not inventing one per environment.
Two consequences, and the second is the dangerous one.
The obvious cost is that a rule written against raw field names only works for the source it was written against. Move it, and you rewrite it.
The quiet cost is what happens when a field name changes underneath you. A condition matching a field that no longer exists does not fail. It matches nothing. No error, no warning, no drop in dashboard health, because the rule is still enabled and still running. You lose coverage and gain no signal that you lost it.
That is the same failure mode as a log source going silent, arriving through a different door.
So write detections against normalised fields, and when a log source is upgraded, check the rules that read from it. Not because they will break loudly, but because they will not.
CHECK YOURSELF
You write a rule against src_ip. The vendor renames it to source.address in an update. What happens?
SHOW THE ANSWER
The rule stops matching and reports nothing, quietly
Why. A field that does not exist does not error, it simply never matches. The rule stays green, the dashboard stays calm, and coverage is gone with no signal that anything changed. This is why silence needs monitoring as much as volume does.