Schema Unification — ECS, OCSF, and Splunk CIM

You have three log sources: a Windows endpoint, an AWS CloudTrail trail, and a Linux auditd daemon. Each calls the same concept — “what command ran” — something different: CommandLine, requestParameters, and comm. How do you write one detection rule that covers all three?

This is the schema problem. Schema standards are the solution.

Why Schema Matters for Detection

Schema normalization solves two problems:

1. Query reuse: Write a KQL query that finds lateral movement using process.parent.name. That query works against Windows events, Sysmon, and EDR telemetry — as long as they all normalize to ECS.

2. Cross-source correlation: Correlating a Windows process creation event with a network connection event requires that both use the same field name for the host identifier (host.name, not Computer in one and hostname in the other).

Without normalization, every new data source requires:

• New field mappings in every detection rule
• New dashboards for every log source
• New analyst training for every schema variant

Elastic Common Schema (ECS)

ECS is the de facto standard for Elastic-based SIEMs and is the schema Sigma’s Elastic backend targets.

Core ECS field groups

process.*         — processes
  process.name            = "cmd.exe"
  process.executable      = "C:\Windows\System32\cmd.exe"
  process.command_line    = "cmd.exe /c whoami"
  process.pid             = 4392
  process.parent.name     = "explorer.exe"
  process.parent.pid      = 2916

user.*            — actors
  user.name               = "jdoe"
  user.domain             = "CORP"

network.*         — connections
  network.direction       = "egress"
  source.ip               = "10.0.0.1"
  destination.ip          = "185.220.101.5"
  destination.port        = 443

event.*           — metadata
  event.category          = ["process"]
  event.type              = ["start"]
  event.action            = "process_started"
  event.outcome           = "success"

file.*            — files
  file.path               = "C:\Users\jdoe\Downloads\evil.exe"
  file.name               = "evil.exe"
  file.hash.sha256        = "abc123..."

Splunk CIM (Common Information Model)

Splunk CIM organizes fields into data models — logical groupings of related events with defined required fields.

Key CIM data models for detection

A CIM-normalized Splunk query looks like:

| datamodel Endpoint Processes search
| where Processes.process_name = "powershell.exe"
| table Processes.dest, Processes.user, Processes.process, Processes.parent_process

This query runs against Windows, macOS, and Linux events — as long as each has a CIM-compatible add-on installed.

OCSF (Open Cybersecurity Schema Framework)

OCSF is the newest of the three and the most ambitious — a vendor-neutral standard backed by AWS, Splunk, IBM, CrowdStrike, Palo Alto, and 15+ others. It’s the schema for AWS Security Lake.

Unlike ECS (which is field-centric), OCSF is event class-centric. Every event belongs to a class with a defined structure:

{
  "class_uid": 1001,
  "class_name": "File System Activity",
  "activity_id": 1,
  "activity_name": "Create",
  "time": 1710497794000,
  "actor": {
    "process": {
      "name": "cmd.exe",
      "pid": 4392,
      "file": { "path": "C:\\Windows\\System32\\cmd.exe" }
    },
    "user": {
      "name": "jdoe",
      "domain": "CORP"
    }
  },
  "file": {
    "path": "C:\\Users\\jdoe\\AppData\\Local\\Temp\\payload.exe",
    "name": "payload.exe"
  },
  "severity_id": 3,
  "status_id": 1
}

OCSF’s event classes cover: Authentication (3002), Network Activity (4001), Process Activity (1007), File System Activity (1001), DNS Activity (4003), and more.