OCSF Extension Proposals
Several technique-level detection rules in this framework require fields that are not present in the OCSF base schema. Rather than silently relying on vendor-specific fields, these are documented here as formal proposals for the OCSF working group. Each proposal names the missing field, explains why no existing field suffices, and provides a concrete schema suggestion.
api.name proposed The name of the Windows API function used to perform a cross-process operation. Required to distinguish injection primitives at the sub-technique level — CreateRemoteThread from QueueUserAPC from other injection methods.
Motivation
OCSF Process Activity (class 1007) with activity_id = Inject captures that a cross-process write occurred but not which Windows API was used to accomplish it. Sub-techniques T1055.001 (DLL Injection) and T1055.004 (APC Injection) are formally defined by their injection primitive — the invariant field that differentiates them from each other and from the parent technique. Without api.name, both sub-techniques are indistinguishable from each other and from T1055 at the OCSF event level. Classic Sysmon surfaces this partially via EID 8 (CreateRemoteThread) as a dedicated event class, but has no equivalent for QueueUserAPC. A unified api.name field across all OS API call events would allow consistent sub-technique discrimination.
Proposed schema
Object: Event-level field on Process Activity (1007), activity_id = Inject Field: api.name Type: string — the Win32 or NT API function name Example: 'CreateRemoteThread', 'QueueUserAPC', 'NtCreateThreadEx' Add api.name as a top-level field on Process Activity events when the activity describes a specific OS API call. Vendors normalising Sysmon EID 8 map the implicit event type → api.name: 'CreateRemoteThread'. Kernel ETW sources provide this for other primitives.
Sigma usage
detection:
selection:
activity_id: 'Inject'
api.name: 'CreateRemoteThread'
condition: selection process.access_mask proposed The access rights requested when opening a handle to an existing process. Required to distinguish a benign process open (e.g. read name only) from a credential-dumping open (PROCESS_VM_READ).
Motivation
OCSF Process Activity (class 1007) with activity_id = Open (3) captures that a process handle was opened but not the access mask that was requested. For LSASS credential dumping, the critical invariant is that the handle carries PROCESS_VM_READ rights — without this field the event is indistinguishable from a legitimate process open. Classic Sysmon captures this as GrantedAccess on Event ID 10 (ProcessAccess); the OCSF base schema has no equivalent.
Proposed schema
Object: Process (used in Process Activity, activity_id = Open) Field: access_mask Type: string (hex bitmask) or integer Example: "0x0010" (PROCESS_VM_READ) Add access_mask to the OCSF Process object, populated only when the event describes an OpenProcess-style handle acquisition. Vendors that normalise Sysmon EID 10 map GrantedAccess → process.access_mask.
Sigma usage
detection:
selection:
activity_id: 'Open'
process.access_mask: '0x0010' # PROCESS_VM_READ
process.name: 'lsass.exe'
condition: selection process.integrity_level proposed The Windows Mandatory Integrity Control level of a process (Low, Medium, High, System). Required to detect UAC bypass: the defining invariant is a High-integrity process spawned from a Medium-integrity parent without a UAC consent event.
Motivation
OCSF Process Activity (class 1007) with activity_id = Launch (1) captures process creation but does not model Windows integrity levels. UAC bypass detection depends entirely on observing the integrity level transition — a process spawned at High integrity from a Medium-integrity actor, without a preceding consent prompt. Classic Sysmon captures this as IntegrityLevel on Event ID 1; OCSF has no equivalent. The field is Windows-specific but the pattern generalises to any capability-based privilege model.
Proposed schema
Object: Process (used in Process Activity, activity_id = Launch) Field: integrity_level Type: string enum — 'Low' | 'Medium' | 'High' | 'System' | 'Untrusted' Scope: Windows-specific; omitted on non-Windows platforms Add integrity_level to the OCSF Process object, populated on process creation events on Windows. Vendors that normalise Sysmon EID 1 map IntegrityLevel → process.integrity_level.
Sigma usage
detection:
selection:
activity_id: 'Launch'
actor.process.integrity_level: 'Medium'
process.integrity_level: 'High'
condition: selection process.start_type proposed The creation flags passed to CreateProcess, specifically whether the process was created in a suspended state. Required as the earliest observable signal for process hollowing.
Motivation
Process Hollowing creates a legitimate process in suspended state (CREATE_SUSPENDED), unmaps its image, and writes attacker code into the vacated address space before resuming execution. The suspended-state creation is the only event that fires before the image replacement occurs and is therefore the earliest detection opportunity. OCSF Process Activity (class 1007) with activity_id = Launch (1) does not capture the creation flags. Classic Sysmon Event ID 1 also does not expose this flag; it requires kernel ETW (Microsoft-Windows-Kernel-Process) or EDR telemetry that captures the creation flags directly.
Proposed schema
Object: Process (used in Process Activity, activity_id = Launch)
Field: start_type
Type: string enum — 'Normal' | 'Suspended' | 'Debug' | 'Detached'
(maps to Windows PROCESS_CREATION_FLAGS; simplified subset)
Scope: Windows-specific; omitted on non-Windows platforms
Add start_type to the OCSF Process object, populated on process creation
events where the creation flags are available. The primary value is the
'Suspended' variant for hollowing detection. Sigma usage
detection:
selection:
activity_id: 'Launch'
process.start_type: 'Suspended'
condition: selection managed_entity.policy.type proposed The policy engine a managed policy entity belongs to (Active Directory Group Policy, Intune configuration profile, Entra Conditional Access, etc.). Required to separate Group Policy Modification from its sibling domain/tenant policy modifications.
Motivation
OCSF Entity Management (class 3004) with managed_entity.type = Policy captures that a policy was updated, which is enough to express the parent technique T1484 (Domain or Tenant Policy Modification). The sub-technique T1484.001 constrains the Artifact slot to Group Policy specifically, and the OCSF Policy object (name, uid, version, desc, group, data) has no field that names the policy engine. Natively, Windows splits a single Group Policy change across several surfaces: Security EventID 5136 on a groupPolicyContainer object, 5136 on gPLink/gPOptions of a site, domain, or OU, and file writes to the GPO template under SYSVOL. A normalised policy.type lets all three collapse into one event that a single rule can match.
Proposed schema
Object: Policy (used as managed_entity.policy in Entity Management, class 3004)
Field: type
Type: string — the policy engine / policy system name
Example: 'Group Policy', 'Intune Configuration Profile',
'Conditional Access'
Add type to the OCSF Policy object. Vendors normalising Windows
EventID 5136/5137 on groupPolicyContainer objects, 5136 on gPLink /
gPOptions, and SYSVOL\<domain>\Policies\ file writes map all
three to activity_id = Update with policy.type = 'Group Policy'. Sigma usage
detection:
selection:
activity_id: 'Update'
managed_entity.type: 'Policy'
managed_entity.policy.type: 'Group Policy'
condition: selection