OCSF and operational technology: the ICS field-extensions proposal.

The Network Activity class in current OCSF carries the IT-network primitives an analyst expects: source and destination endpoints, ports, protocol numbers, byte counts, service names. None of those carry the information an ICS analyst needs to investigate Modbus, DNP3, or BACnet traffic. The function code embedded in a Modbus PDU isn't a port; it's a one-byte value that distinguishes a read-coils request from a write-multiple-registers command. Whether a DNP3 frame is a request, a response, or an unsolicited response isn't a TCP flag; it's an application-layer attribute that anomaly detection depends on. The object type a BACnet frame addresses isn't a hostname; it's a controller-specific identifier that says whether you're touching an analog input or a binary output.

Today an OCSF-normalized ICS pipeline either drops these attributes at the transformation step or smuggles them through in unstructured fields. Both options break detection portability. A Sigma rule looking for "any write to a holding register on a safety PLC" can't be expressed against OCSF, because the OCSF event doesn't carry "holding register" anywhere a portable query language can name. The analyst who wants the rule has to write it against the original Zeek conn.log or the original PLC log in vendor format, which puts ICS-aware detection logic permanently on the wrong side of the normalization layer, so whatever the OCSF investment bought at the IT layer never reaches the OT layer.

The gap is structural rather than a missing parser, because the protocol parsers already exist in Zeek and in commercial ICS-aware sensors, so what's actually missing is the schema-level shape that lets the parsed information cross the normalization boundary intact. The Issue #1515 proposal exists because the parsers are ready and the schema is the thing holding the architecture back.

Anomaly detection on function-code distributions

The most common ICS detection pattern is baseline-and-deviate on function-code mix. Modbus traffic on a working manufacturing line is dominated by read operations: function codes 1 (Read Coils), 3 (Read Holding Registers), 4 (Read Input Registers). Writes happen, but the ratio is stable, and the writes that happen are scheduled and addressed to a small set of known registers. An unexpected spike in function code 16 (Write Multiple Registers) addressed to unfamiliar register ranges is the shape of the early stages of an attack against the control logic. Without ics.function_code in the normalized event, that detection can't be made portable across SIEMs or tested with a Sigma rule or evaluated in a cross-engine query, whereas with the field in place the rule comes down to a three-line aggregation.

Unsolicited responses on BACnet and DNP3

Both BACnet and DNP3 support unsolicited responses, where a controller pushes information without having been polled, and the protocol mechanism is legitimate, so in most environments the traffic shape is predictable across HVAC controllers, smart meters, and RTUs. What's not predictable is unsolicited responses arriving from devices that have never sent them before, or arriving in patterns that don't match the normal cadence, and ics.pdu_type = "unsolicited_response" is the field that lets a detection author write "alert me on unsolicited responses from any device not in the configured whitelist." The rule is one line of SQL, and it's the same line of SQL whether the underlying engine is ClickHouse, Trino, or a SIEM, which is exactly the portability OCSF is supposed to provide and currently doesn't.

NERC CIP and IEC 62443 audit posture

The compliance frameworks for energy and industrial automation (NERC CIP for North American bulk electric, IEC 62443 for industrial automation broadly) expect the operator to log control-system access in a way that lets an auditor verify which functions were invoked against which devices. The field shape the auditor wants is what's in the proposal: who connected, what function code they called, which unit and register were addressed, whether the call was a read or a write. The normalized-OCSF version of that audit trail is straightforward once the fields exist; today it requires the auditor to read original vendor logs alongside the OCSF tables, which is the exact friction the compliance framing was supposed to remove.

Threat hunting against TRITON-style and CRASHOVERRIDE-style TTPs

The publicly documented OT-targeted intrusions of the last decade (TRITON against the Schneider Triconex safety system, CRASHOVERRIDE against the Ukrainian grid, STUXNET against Iranian centrifuges) all share a structural property: the attacker eventually issued writes against control points that should have been read-only from the network. A hunt for "writes against the safety-system address range from any host that isn't the engineering workstation" is a one-page query if the data carries ics.function_code and ics.register_address. The hunt isn't theoretical, because publicly available threat intelligence already describes the field-shape sequences that should trigger it, so the bottleneck has been a normalized schema that carries the fields rather than the detection idea itself.

IEC 62443 is the international standards series for industrial automation and control-system security. Part 3-3 specifies system security requirements; Part 4-2 covers component requirements. The audit posture both parts assume is that the operator can produce an event-level record of network access to control devices, with enough detail to demonstrate that unauthorized writes can be detected and investigated. The proposed OCSF fields are the schema shape that makes that posture portable across SIEMs and lakehouses; without them, the operator has to anchor compliance on vendor-specific log formats that the next SIEM migration may break.

NIST SP 800-82 Rev. 3 (Guide to Operational Technology Security, published 2023) makes a similar recommendation in less prescriptive language. The guidance asks for "comprehensive logging of control system communications including command and control messages, configuration changes, and unauthorized access attempts." Comprehensive in this context means the function code is preserved, the unit identifier is preserved, and the addressed register is preserved, which is the same set the proposal adds.

I want to be honest about the standards work. Neither IEC 62443 nor NIST SP 800-82 explicitly requires OCSF; both predate it. What they require is that the operator can produce the audit trail. The argument for the OCSF extension isn't that the standards mandate it; it's that the standards mandate a property (auditability of control-system access) which is materially easier to achieve when the normalization layer carries the protocol-specific fields rather than dropping them.

The IT/OT convergence story has been told the same way for a decade. The IT-side investments (centralized SOC, SIEM, normalized telemetry, detection-as-code) extend to cover the OT-side estate. What's broken about that story in practice is that the IT-side normalization layer doesn't carry OT protocol detail, so the OT events that land in the SOC are either lossy or trapped in vendor-specific shapes that don't query alongside IT events, which leaves SOC analysts maintaining two separate mental models for two separate event languages. The convergence is real on the network and at the procurement layer, but because the detection vocabulary stays split, it hasn't arrived at the layer where analysts actually write rules.

Adding the six fields in Issue #1515 doesn't close that gap by itself. It closes a specific subset of it: the SOC analyst can write a single Sigma rule that joins an OT alert (Modbus write to a safety register) with an IT alert (anomalous SSH from the same source endpoint that issued the write) in a single query against a single normalized table. That join is the part the current OCSF schema can't express. Once it can, the practical IT/OT convergence story gets meaningfully better, because the detection vocabulary is shared.

That's the framing I'd use with an executive sponsor asking why an OCSF schema change matters, because the six fields are less six entries in a spec than a schema-level commitment that the OT side counts as a first-class citizen of the normalized telemetry plane instead of an afterthought routed around the OCSF layer.