OCSF Field Mapper
Map your custom log source fields to the Open Cybersecurity Schema Framework. Write detection rules that work across every source.
- Covers all OCSF v1.1 event classes and field paths
- Handles proprietary field names via heuristic matching
- Flags unmapped fields and suggests OCSF alternatives
- Exports a mapping configuration for Cribl, Vector, and Fluent Bit
OCSF mapping result
Example: custom network sensor log source
| Source field | OCSF path | Status |
|---|---|---|
| src_ip | src_endpoint.ip | Mapped |
| dst_ip | dst_endpoint.ip | Mapped |
| user | actor.user.name | Mapped |
| event_id | metadata.original_uid | Mapped |
| process_name | process.name | Mapped |
| sha256 | file.fingerprints[sha256] | Mapped |
Mapping summary
6/6 fields mapped — OCSF class: Network Activity (4001)
0 unmapped fields · 0 transformation warnings
How this tool works
Paste a sample event or field list
Input your raw log event as JSON, or paste a list of field names from your custom log source.
Select your source type
Choose the closest source category (network, authentication, process, file, cloud resource) to help the mapper apply the right OCSF class context.
Review the OCSF mapping table
The mapper outputs a field-by-field mapping table showing the OCSF field path, data type, and any transformation notes for fields that require normalisation.
What to do with the result
Integrate with your pipeline
Use the mapping table as input to your log pipeline (Cribl, Vector, Fluent Bit) to normalise events at ingest time.
Submit to the OCSF project
If you have mapped a novel source, consider contributing your profile to the OCSF open-source schema project on GitHub.
Enable cross-source detection
OCSF-normalised events allow detection rules to operate across source types without field aliasing per rule.
OCSF field mapper: frequently asked questions
What is OCSF and why does it matter?
The Open Cybersecurity Schema Framework (OCSF) is a vendor-neutral, open standard for normalising security event data. When all your log sources share a common field schema, you can write one detection rule that works across cloud, endpoint, identity, and network events without source-specific field aliases.
Which OCSF version does the mapper use?
The mapper uses OCSF v1.1.0. The tool is updated within 30 days of each OCSF schema release. Field paths are referenced as dot-notation strings compatible with the official OCSF schema repository.
How does ManySignal use OCSF internally?
ManySignal normalises all ingested events to OCSF at the entity graph layer. This means detection rules, behavioral analytics, and investigation timelines all operate on OCSF-aligned fields regardless of source. No field aliasing is required per rule.
What OCSF event classes does the mapper cover?
The mapper covers all OCSF 1.1 event classes including: Authentication (3002), Network Activity (4001), Process Activity (1007), File System Activity (1001), Registry Key Activity (201001), Cloud Resource Activity, DNS Activity, HTTP Activity, and the base Event class shared by all.
Can I map fields from proprietary log formats?
Yes. If your source uses proprietary field names (common in legacy SIEM environments, custom application logs, or niche security tools), paste a sample event and the mapper will suggest the closest OCSF field based on field name heuristics and value type inference.
What if my source has fields with no OCSF equivalent?
OCSF includes an unmapped object for vendor-specific fields that have no standard equivalent. The mapper flags these and suggests placing them in the unmapped dictionary with documentation. You can also propose new OCSF fields through the schema governance process.
Is the OCSF field mapper integrated with ManySignal's ingestion pipeline?
Yes. ManySignal's connector framework includes a built-in OCSF mapping layer. For sources without a native ManySignal connector, you can provide a custom field mapping configuration using the output from this tool.
Does OCSF normalisation affect detection performance?
Normalisation at ingest adds minimal latency (typically under 5ms per event). The performance gain from writing fewer, simpler detection rules that work cross-source more than compensates for this overhead at scale.
Ingest any log source, normalised to OCSF automatically
ManySignal normalises every event to OCSF at the entity graph layer. Book a demo to see cross-source detection in action.