Log normalization maps events from different sources onto shared field names so one query or rule works everywhere. Two public schemas exist, OCSF and Elastic Common Schema, and a small in-house schema is a sensible third option for teams with few sources. Pick the one your tools can consume.
Why normalize at all
Without it, a failed login is user in one system, userName in another and actor.id in a third. Every detection rule needs three versions, and every analyst must remember which is which. Normalization is the unglamorous step that makes correlation possible, and it is a large part of what a SIEM actually does.
What each option is
OCSF. The Open Cybersecurity Schema Framework. Its site describes event classes organized into categories, among them System Activity, Findings, Identity and Access Management, Network Activity and Discovery, along with objects, data types, a dictionary, profiles and platform extensions. It is a project under LF Projects, LLC.
ECS. Elastic Common Schema is a community supported standard that sets shared field names and Elasticsearch data types for event data such as logs and metrics. Its stated purpose is to encourage users of Elasticsearch to normalize event data so they can analyze, visualize and correlate it.
Your own schema. A short document listing the fields every security event must have, such as those in our field set post.
How to choose
- Your analytics platform is built around one schema: leans toward: That schema
- Many vendors produce events and you want a vendor neutral model: leans toward: OCSF
- You mostly send to an Elasticsearch based stack: leans toward: ECS
- You have under ten sources, all written by your own team: leans toward: Own schema
- You need to change platforms later: leans toward: A public schema, to reduce lock in
Check each project's current documentation before committing. Schemas evolve, and versions matter.
Where to normalize
- At the source. Best if you control the code. Emit the target field names directly.
- In the collector. A pipeline stage renames and restructures fields from third party sources.
- At query time. Flexible but slower, and every analyst must know the mapping.
Normalizing at the source for your own services and in the collector for everything else is the usual split.
Keep the raw event
Always retain the original message next to the mapped fields. Mappings have bugs. When one is found, you can reprocess from the raw data. Without it, you are stuck with the mistake.
Practical steps
- List your top ten sources by security value.
- Choose a schema.
- Map the five fields you query most: time, actor, action, target, outcome.
- Test with one real investigation question across sources.
- Add fields only when a rule or question needs them.
Quick check
Do I need to map every field?
No. Map the ones you use for detection and investigation, and keep everything else in the raw event.
Is a schema the same as a log format?
Not quite. A format is how an event is serialized, such as JSON. A schema defines the names and meaning of the fields inside it.
Sources
Last reviewed: 19 October 2026.
