They miss because the rule still looks for source names such as Image or ParentImage while the normalized event exposes process.path and process.parent_process.path. The facts are present, but the matcher fails when the detection layer does not translate meaning across schemas.
Why Schema Translation Breaks Stock Sigma Rules
Stock Sigma rules often miss after schema normalisation because detection content is usually written against field names and event conventions from a specific log source, then reused in an environment where those facts are represented differently. When a normaliser maps Image to process.path or ParentImage to process.parent_process.path, the underlying behaviour has not changed, but the rule logic still depends on the original vocabulary. That makes the failure semantic rather than factual, which is why it is easy to misread as a data-quality problem.
For teams that rely on Sigma as a portable detection layer, the important point is that portability depends on meaning-preserving translation, not just field presence. A rule can be technically valid and still become ineffective if the pipeline does not preserve source-to-normalized equivalence for process, parent-process, command line, and other high-value telemetry fields. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames the broader expectation that security monitoring depends on controlled, reliable telemetry handling rather than ad hoc field reuse. In practice, many security teams discover this only after a healthy-looking rule library stops matching once data is normalised into a different schema.
How Normalised Fields Change Detection Logic
Normalisation changes the contract between the event and the rule. A raw Windows process creation event may expose source-specific fields like Image and ParentImage, while a unified schema may expose process.path, process.parent_process.path, and process.command_line. If the Sigma rule was written for the source schema, the detection engine must either translate the rule at compile time or maintain a lookup layer that preserves the original semantics. If neither happens, the event can contain all the right facts and still never satisfy the matcher.
The practical issue is not only field renaming. Normalisers may also change nesting, data types, casing, or how missing values are represented. A detection that expects a flat string can fail against a nested object, and a rule that assumes a parent-child relationship by name can fail when the relationship is reconstructed by parsing instead of directly emitted by the source. That is why portability claims need testing against representative normalised events, not just against the original log format.
- Source schemas encode meaning through field names, hierarchy, and event IDs.
- Normalised schemas preserve meaning only if the mapping is complete and consistent.
- Detection engines need rule translation, field aliases, or schema-aware content engineering.
- Validation should compare expected matches before and after normalisation on the same event set.
The guidance breaks down when the normalised schema compresses distinct source fields into one generic structure without enough context to reconstruct the detection condition.
Where Portability Fails in Real Deployments
Tighter schema standardisation often improves interoperability, but it also increases the risk of false portability when teams assume that every source-specific rule will survive translation unchanged. The most common edge case is partial mapping: the normaliser supports the main process fields but drops a less common value that the rule quietly depended on, such as a parent relationship, file metadata, or command-line fragment. Another edge case is one-to-many ambiguity, where several source fields collapse into a single normalised field and the rule can no longer distinguish the original condition.
There is also a consensus gap in how much translation should occur inside the rule engine versus inside the telemetry pipeline. Some teams prefer to author detections against a canonical schema and let ingestion handle source variance; others keep source-native rules and translate them later. Both approaches can work, but the failure mode changes. Canonical-first reduces rule drift, while source-native can preserve nuance for a specific telemetry family. The wrong choice is treating schema normalisation as a purely cosmetic layer, because detection effectiveness depends on the preserved relationship between fields, not just on their names.
For process telemetry, this becomes especially visible when analysts expect a match on process lineage but the normalised event only preserves the child process path. If the parent value is missing, renamed inconsistently, or represented differently across collectors, the rule may remain silent even though the behaviour is present.
Risk and Threat Considerations
The material risk is missed detection, which creates blind spots in alerting, hunting, and triage workflows. Schema normalisation can reduce observability if the translation layer does not preserve the exact semantics that a stock Sigma rule expects. That risk matters most where detections are used as a control dependency for compromise identification, because a silent miss can delay containment even though the telemetry was collected.
Failure mechanism: The rule matcher evaluates source-specific field names or structures after the event has been transformed into a different schema, so the condition never evaluates as true. The failure is usually caused by incomplete field mapping, nested-versus-flat mismatches, type changes, or loss of source context during ingestion and parsing.
Impact: Events that should have matched remain undetected, which weakens monitoring confidence, increases dwell time risk, and can create inconsistent coverage across data sources that appear standardised on paper.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 8 — Audit Log Management | Schema-normalized detections rely on usable log content and consistent field handling. |
| Recommendation — Validate log normalization so detections still match the intended security events. | ||
| NIST CSF 2.0 | DE.CM-1 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Missed Sigma matches weaken continuous monitoring of telemetry after transformation. |
| DE.CM-7 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Normalized schemas can break security detection if event meaning is not preserved. | |
| Recommendation — Confirm transformed telemetry still supports monitoring use cases and expected detections. Test detection coverage after normalization to ensure monitoring remains effective. | ||
| MITRE ATT&CK | T1057 — Process Discovery | Process-path fields are central to detections built on process execution lineage. |
| T1059 — Command and Scripting Interpreter | Many Sigma rules key on process and command-line evidence of execution behavior. | |
| Recommendation — Map process-lineage rules to normalized process fields and verify matches on test events. Align execution detections to canonical command-line fields before relying on them. | ||
Practitioner Guidance
What to verify: Test every high-value Sigma rule against the normalised event, not just the raw source event. The key question is whether the rule still matches the same behaviour after field translation, especially for process lineage, parent-child relationships, and command-line conditions.
Decision rule: If a rule depends on source-native field names or hierarchy, treat it as schema-bound until you have an explicit translation layer or a rewritten canonical version. If a detector only works before normalisation, it is not yet portable, even if it looks portable in documentation.
What practitioners underestimate: Misses often originate from semantic drift rather than outright data loss. Teams may spend time tuning thresholds or hunting for ingest failures when the real issue is that the normalized schema preserved the event object but not the rule's meaning.
Practitioner takeaway: Treat schema normalisation as a detection-engineering problem, not a formatting problem, because a rule that cannot survive translation is not operationally reliable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
