OCSF schema

Falak implements a deliberate subset of OCSF v1.3 — only the classes a Linux, Kubernetes and cloud runtime sensor can populate with high fidelity. Adding a class is a deliberate act requiring a probe that can fill it and a storage projection that can hold it.

Classes#

type_uid#

The single most important identity in the schema:

type_uid = class_uid × 100 + activity_id

It must be computed, never guessed. Core rejects an event whose type_uid does not match its class_uid and activity_id. The identity holds for the extension class too: 990001 × 100 + 1 = 99000101.

Activity ids by class#

Severity#

severity_id follows OCSF exactly:

Base attributes#

Every class embeds the same base object:

{
  "activity_id": 1,
  "category_uid": 1,
  "class_uid": 1007,
  "type_uid": 100701,
  "time": 1763458204119,
  "severity_id": 1,
  "status_id": 1,
  "metadata": {
    "version": "1.3.0",
    "product": { "name": "falak-neo-minion", "vendor_name": "Falak Neo", "version": "1.7.2" },
    "correlation_uid": "4f2c…",
    "uid": "9c2f…",
    "logged_time": 1763458204119,
    "sequence": 8412093
  },
  "device": { "uid": "…", "hostname": "…", "os": {}, "container": {}, "k8s": {} },
  "actor": { "process": {}, "user": {}, "session": {} },
  "cloud": { "provider": "aws", "region": "eu-central-1", "account": {} },
  "observables": [],
  "enrichments": []
}

Falak additions#

Falak adds a small number of fields inside standard classes rather than inventing classes. Each exists because a detection needed a fact the base schema does not carry.

The extension class#

OCSF has no container lifecycle class. Rather than bend Process Activity out of shape for CRI events, Falak registers one documented extension:

• Extension namespace falak, extension uid 990
• class_uid = 990001, category_uid = 1

It carries the container object, the K8s context, the init process, the mount set (with is_host_path and is_sensitive), port mappings, and the full SecurityContext including privileged, host_pid, host_network and capability adds and drops.

The mount set is what makes container-escape detection possible: a hostPath mount alone is posture, but a hostPath mount followed by an exec whose resolved inode lives on the host device is an escape in progress.

Detection Finding#

2004 is emitted by core, never by a sensor. Its finding_info object carries:

• analytics[] — the rule or model that fired, with its source repository
• attacks[] — at least one ATT&CK technique, required by Law 5
• related_events_uids[] — the evidence chain
• kill_chain[] — the phases the behaviour spans

{
  "class_uid": 2004,
  "finding_info": {
    "uid": "b7f1…",
    "title": "Fileless execution from an anonymous memory file descriptor",
    "analytics": [{ "uid": "1f1b8d3a-…", "type_id": 2, "source_repo": "falak" }],
    "attacks": [{ "uid": "T1620", "name": "Reflective Code Loading",
                  "tactic": { "uid": "TA0005", "name": "Defense Evasion" } }],
    "related_events_uids": ["9c2f…", "4a71…"]
  },
  "risk_score": 88,
  "confidence_id": 3
}