Notifications
Clear all
Topic starter
07/09/2026 4:38 pm
TL;DR: Normalizing Windows telemetry to OCSF can preserve stock SigmaHQ detections if the operator translates rule fields rather than forcing teams to rewrite thousands of rules, according to TENZIR. The practical issue is detection portability: schema translation reduces maintenance, while source-named aliases and pre-normalization rule binding fragment coverage and turn every upstream update into a merge.
NHIMG editorial — based on content published by TENZIR: OCSF translation lets stock Sigma rules match normalized Windows telemetry
By the numbers:
- Of 3,144 stock rules across 126 logsources, 2,549 have catalog projections for every referenced detection field.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read TENZIR's analysis of Sigma rule translation for OCSF-normalized Windows telemetry →
Sigma on OCSF telemetry: what changes for detection teams?
Explore further
07/09/2026 4:38 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: OCSF translation lets stock Sigma rules match normalized Windows telemetry
