Map to other schemas

This guide provides brief guidance on mapping data to schemas other than OCSF. While OCSF is the recommended choice for security data, you may need to support Elastic Common Schema (ECS), Google UDM, Microsoft ASIM, or another platform-specific schema.

Use Map to UDM and Map to ASIM for the dedicated Google UDM and Microsoft ASIM workflows.

Choosing a schema

Schema	Best For	Considerations
OCSF	Security data normalization	Vendor-neutral, comprehensive security focus
ECS	Elasticsearch/Elastic Stack	Tight Elastic integration, good field coverage
UDM	Google SecOps	Required for SecOps, API-oriented UDM shape
ASIM	Microsoft Sentinel	Required for Sentinel, KQL-optimized

Recommended approach

Map to OCSF first, then translate to other schemas as needed. This gives you a single source of truth and reduces maintenance burden.

Elastic Common Schema (ECS)

ECS is Elastic’s open schema for structured data in Elasticsearch.

Key differences from OCSF

• Field names use dots instead of nesting: source.ip vs src_endpoint.ip
• Less prescriptive about field values
• Wider scope (not security-specific)

Mapping pattern

// From OCSF to ECS
ecs.source.ip = ocsf.src_endpoint.ip
ecs.source.port = ocsf.src_endpoint.port
ecs.destination.ip = ocsf.dst_endpoint.ip
ecs.destination.port = ocsf.dst_endpoint.port
ecs.event.category = ["network"]
ecs.event.type = ["connection"]
ecs.network.protocol = ocsf.connection_info.protocol_name
ecs.network.bytes = ocsf.traffic.total_bytes
ecs.@timestamp = ocsf.time

ECS field sets

Common ECS field sets for security data:

• event.* - Event metadata and classification
• source.* / destination.* - Network endpoints
• process.* - Process information
• file.* - File metadata
• user.* - User information
• host.* - Host/device details
• threat.* - Threat intelligence

Microsoft ASIM

ASIM (Advanced Security Information Model) is Microsoft Sentinel’s normalization schema. Use Map to ASIM for the detailed ASIM mapping workflow.

Key differences from OCSF

• Designed for KQL queries
• Uses specific parser naming conventions
• Column-oriented naming style

ASIM schemas

ASIM provides schemas for:

• Network sessions
• Authentication events
• DNS activity
• Web sessions
• Process events
• File activity
• Audit events

Translation strategies

Direct field mapping

When fields have direct equivalents:

ecs.source.ip = ocsf.src_endpoint.ip

Value transformation

When values need conversion:

// OCSF uses integers, ECS might use strings
ecs.event.severity = ocsf.severity_id.string()

Structural transformation

When structure differs:

// OCSF nested to ECS flat
ecs.source.ip = ocsf.src_endpoint.ip
ecs.source.port = ocsf.src_endpoint.port
ecs.source.bytes = ocsf.traffic.bytes_out

Enum mapping

When schemas use different enumerations:

let $severity_map = {
  1: "low",
  2: "medium",
  3: "high",
  4: "critical",
}
ecs.event.severity_name = $severity_map[ocsf.severity_id]

Maintaining multiple schemas

If you need to support multiple target schemas:

1. Normalize to OCSF first as your canonical format
2. Create translator operators for each target schema
3. Branch pipelines based on destination

// Central normalization
from_kafka "raw-events"
my_source::ocsf::map  // Normalize to OCSF

// Branch to different destinations
fork {
  // Send OCSF to data lake
  to_kafka "ocsf-events"
}
fork {
  // Translate and send to Elasticsearch
  ocsf_to_ecs
  to_opensearch "https://elasticsearch.example.com:9200", action="index", index="ecs"
}
fork {
  // Translate and send to Google SecOps
  ocsf_to_udm
  to_google_secops "..."
}

See Also

• to_opensearch
• Map to OCSF
• Map to UDM
• Map to ASIM
• Transform values