OCSF translation lets stock Sigma rules match normalized Windows telemetry

At a glance

What this is: This analysis shows that Sigma rules can still fire on OCSF-normalized Windows telemetry when field predicates are translated to the normalized schema instead of being rewritten by hand.

Why it matters: It matters to SOC, detection engineering, and SIEM teams because schema normalization only helps if rule logic can follow the same meaning across sources without breaking upstream content maintenance.

By the numbers:

• Of 3,144 stock rules across 126 logsources, 2,549 have catalog projections for every referenced detection field.

👉 Read TENZIR's analysis of Sigma rule translation for OCSF-normalized Windows telemetry

Context

Windows telemetry normalization often fails when detections stay tied to source-specific field names. If one producer names a process as Image and another as NewProcessName, a literal rule corpus loses coverage unless the detection layer can translate semantics into the normalized schema first. For security teams, the governance question is not whether normalization is useful, but whether it preserves existing detection content without creating a permanent field-mapping burden.

This article sits at the intersection of cyber operations and identity-adjacent telemetry governance. Process events carry user, parent-child process, and command-line context that SOC teams use to detect suspicious execution paths, so the quality of schema translation directly affects alert fidelity and analyst trust. In practice, this is typical for multi-source Windows detection pipelines, where the same facts arrive through different producers and must be normalised without weakening detection logic.

Key questions

Q: How should security teams keep Sigma detections working after normalising telemetry to OCSF?

A: Keep the detection logic tied to semantic field translation, not to source-specific field names. Build a governed mapping catalog that resolves each Sigma predicate to the correct OCSF path for every supported logsource, then test translated rules against representative events from each producer before rollout.

Q: Why do stock Sigma rules miss events after schema normalisation?

A: 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.

Q: What tells you that Sigma-to-OCSF translation is failing in production?

A: A growing gap between normalized telemetry volume and rule hit rates is the clearest sign, especially when the same activity still appears in raw events from source producers. You should also watch for unmapped fields, missing logsource projections, and translated rules that stop matching after upstream rule updates.

Q: Should teams rewrite Sigma rules for OCSF or translate rules at query time?

A: Translate at query time whenever possible. Rewriting thousands of rules into OCSF paths creates a permanent maintenance fork, while rule translation preserves upstream community content and lets one normalized event model support multiple Windows producers without duplicating detection logic.

Technical breakdown

Why source-named fields break stock Sigma rules

Sigma rules are usually written against producer-specific log fields, while OCSF aims to normalize those fields into a common event model. The failure mode is simple: a literal matcher expects Image or ParentImage, but the normalized record contains process.path and process.parent_process.path. Without a translation layer, the same security event becomes invisible to the detection content even though the underlying facts are unchanged. The core architectural issue is semantic mismatch, not rule quality.

Practical implication: detection platforms need field translation at query time, not manual rule rewriting per source schema.

How rule translation preserves detection semantics

The sigma operator in this model rewrites rule predicates to the OCSF paths that carry equivalent meaning, guided by logsource. That matters because the event itself remains unchanged while only the rule is adapted to the schema. In the article's Windows example, Sysmon event 1 and Security 4688 both map to the same normalized process activity, so one stock rule can match both producers without duplicating detection content. Translation also needs value reconstruction for fields such as hashes, user identities, and integrity labels.

Practical implication: maintain a mapping catalog that resolves field equivalence and value reconstruction for each supported logsource.

What coverage analysis reveals about normalization maturity

Coverage numbers show how much of a rule corpus can be projected cleanly into the normalized model, but they do not prove that every rule will behave correctly in production. The article's 81.1% figure measures static field coverage only. That means completeness, modifiers, and actual event contents still determine whether a translated rule fires as intended. For mature detection engineering, coverage analysis is a starting point for prioritization, not a substitute for validation.

Practical implication: treat translation coverage as a governance metric and still test translated rules against representative telemetry.

NHI Mgmt Group analysis

Schema translation is now a detection governance problem, not just an engineering convenience. The article shows that normalisation only delivers value when rules can inherit meaning across schemas without manual forks. That shifts control ownership from one-off parser work to governed field-equivalence management across Windows sources, which is a better fit for large SOC content libraries.

Detection content that depends on source names will always fragment as telemetry diversity grows. Sysmon, Security 4688, and other Windows producers describe the same activity differently, so preserving analytic fidelity requires a stable semantic layer. This is a classic example of how operational security tooling drifts when governance does not sit above source-specific implementation details.

Field coverage should be treated as an operational control metric. The article's coverage view is useful because it exposes where mapping gaps will suppress detections before an analyst ever sees them. That makes coverage analysis part of detection engineering governance, not an implementation afterthought.

Named concept: semantic rule portability. This is the ability for a detection rule to survive schema changes without being rewritten for each producer. For SOC teams, semantic portability is what separates scalable content management from perpetual rule maintenance, and it should be measured as a programme capability.

OCSF and Sigma only work together when the translation boundary is tightly governed. If the translation layer is wrong, the rule fires on the wrong field or misses the event entirely. Practitioners should therefore treat mapping catalogs, logsource scoping, and translated-rule validation as first-class detection controls.

What this signals

Detection teams should expect schema-normalization projects to fail if the translation layer is not governed as part of content operations. The useful question is no longer whether events are normalized, but whether translated detections still preserve analyst-relevant meaning across producers and schema drift.

Semantic rule portability: This is the programme capability that lets detection content survive schema differences without becoming a one-off rewrite exercise. Teams that can measure portability can also measure coverage, which turns content maintenance into an operational control rather than an informal engineering task.

For security leaders, the next step is to align normalization work with detection engineering quality checks using the NIST Cybersecurity Framework 2.0 and the NIST SP 800-53 Rev 5 Security and Privacy Controls. That framing makes field mapping, validation, and content portability part of the control environment, not a tooling preference.

For practitioners

• Implement a governed field-equivalence catalog Map each Sigma detection field to its OCSF equivalent by logsource, then version that mapping alongside detection content so updates remain auditable.
• Test translated rules against representative Windows producers Run the same stock Sigma rule against Sysmon and Security 4688 telemetry after normalization to confirm the translated predicates still match the intended process activity.
• Measure translation coverage before rollout Track how many rules in each logsource have complete projections into the normalized schema, and prioritise unmapped fields that suppress high-value detections.
• Validate value reconstruction for hashes and user fields Check that hash algorithms, usernames, and integrity labels are rebuilt from the correct normalized objects, because broken reconstruction will create false negatives or false joins.

Key takeaways

• Normalising telemetry only helps if detection logic can follow the same meaning across schemas.
• Field coverage is a governance signal, but it does not prove that translated detections will fire correctly in production.
• Detection engineering teams should treat semantic rule portability as a control objective, not a convenience feature.

Key terms

• Semantic Rule Portability: The ability for a detection rule to keep its meaning when telemetry is normalized or re-labeled across source systems. In practice, this means the analytic can be translated to the right schema without rewriting its logic for every producer or event format.
• Field Equivalence Mapping: A governed catalog that declares which fields from different log sources represent the same security fact. It is the bridge between source schemas and a normalized model, and it must be versioned, validated, and scoped by logsource to avoid false matches or missed detections.
• Logsource: The contextual label that tells a detection engine what kind of telemetry a rule expects. In Sigma-style content, logsource is what constrains translation and matching so a process-creation rule is not applied to unrelated event types or domains.
• OCSF Process Activity: A normalized event category for process launches and related execution context. It allows different Windows producers to express the same activity through a common structure, which makes rule translation possible without altering the original source event.

What's in the full article

TENZIR's full article covers the operational detail this post intentionally leaves for the source:

• The full rule translation mapping between Sigma field predicates and OCSF process activity fields for Windows sources.
• The concrete SigmaHQ rule examples and the translated observables that appear after normalization.
• The coverage breakdown across 126 logsources, including the rule families that are fully mapped and the ones still missing projections.
• The demo pipeline and replay setup used to validate that stock rules still fire after translation.

👉 TENZIR's full article shows the mapping catalog, translated rule output, and coverage results in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives identity and security practitioners a practical foundation for governing access patterns that underpin modern detection and automation.