Integrating OT Monitoring with Existing SIEM and SOC: Data, Formats and Added Value

The SOC That Cannot See Half the Company

A mid-sized manufacturing organization may have a well-configured IT SIEM, perhaps a SOC managed by an external provider, endpoint detection on workstations, email security and aggregated firewall logs. Yet this monitoring system is blind to everything happening on the OT network.

This is not a matter of skills or goodwill: it is a matter of data. The SIEM only aggregates what the sources send it. If OT devices do not generate events in a format the SIEM understands, they simply do not exist as far as the SOC is concerned. A PLC queried by an unauthorized host, an HMI that starts communicating with an external IP, an industrial protocol on an anomalous port: none of these events reach the IT SIEM.

The result is an organization that sees the IT half of the company clearly and sees nothing of the OT half. For attackers who follow the IT-OT chain, this selective blindness is a feature, not a bug, of their approach.

Output Formats and OT Event Normalization

The first technical challenge in OT-SIEM integration is normalization. Events generated by an OT monitoring system describe different realities than those of the IT world: a "new device seen on the network" is not an "anomalous login", but both are security events that deserve attention. The SIEM must be able to receive them, index them and correlate them.

The most common output formats for integration with enterprise SIEMs are:

CEF (Common Event Format). Developed by ArcSight and today supported by almost every major SIEM, CEF is a standard for transmitting security events over Syslog. Its key-value pair structure makes it possible to map OT-specific fields (network zone, industrial protocol type, Modbus function code, PLC identifier) into CEF custom fields. Advantage: broad compatibility; drawback: the semantic richness of OT events is partly lost when compressed into the standard CEF fields.

LEEF (Log Event Extended Format). An alternative to CEF developed by IBM for QRadar. Similar structure, compatibility mostly within the IBM ecosystem. Preferable if the target SIEM is QRadar.

Syslog with a structured JSON payload. A more modern approach: carrying arbitrarily rich JSON events inside the Syslog payload. The SIEM receives the Syslog message, extracts the JSON and can index any field. It requires a parsing pipeline configured on the SIEM side but offers maximum flexibility to preserve the OT semantics of the events.

REST API / webhook. Some modern SIEMs (Splunk, Elastic SIEM, Microsoft Sentinel) accept events via HTTP API in JSON format. This approach avoids Syslog fragmentation and allows event batches with greater efficiency. It requires network connectivity between the OT network (or the DMZ where the OT collector resides) and the SIEM.

The choice of format depends on the SIEM in use and the expected volume of events. For mid-sized OT environments (hundreds of devices, thousands of events per day), any standard format is adequate. For denser environments, ingestion performance becomes a factor to evaluate.

Which OT Events to Bring into the SIEM and Which to Handle Locally

Not every event generated by OT monitoring needs to reach the SIEM. The selection matters for two reasons: to avoid saturating the SIEM with OT noise that analysts do not know how to handle, and to ensure that high-priority events get the visibility they deserve.

Events that require correlation with IT, or that affect the security of the organization as a whole, should go to the SIEM:

• A new unregistered asset detected on the OT network
• Communication toward external IPs not expected by the baseline, originating from OT devices
• Remote access to OT devices outside authorized windows or without a ticket
• Changes to the configuration of a PLC or HMI (especially outside planned maintenance)
• Anomalous network behavior that could indicate lateral movement (an OT device that starts communicating with zones other than its usual ones)
• Repeated authentication attempts toward OT devices (brute force or credential scanning)
• Detection of exploitation tools or active scanning on the OT network

Local operational handling (not necessarily in the SIEM):

• Process performance anomalies that have no immediate security implications
• OT device availability alerts (a PLC that does not respond: an operational problem, not necessarily security)
• Traffic and bandwidth usage statistics (operational monitoring, not detection)
• Minor baseline variations that fall within the normal behavior of the plant during production changeovers

The export filters toward the SIEM should be configured together with the OT team and reviewed periodically: an event that looks like noise today may become relevant after an incident reveals its meaning.

The Value of IT-OT Correlation

The most powerful use case for OT-SIEM integration is not OT monitoring in itself, which can be done locally. It is the correlation between IT and OT events.

A concrete example: a phishing alert reports that an office user opened a suspicious attachment and contacted a command-and-control domain. This event stays in the IT domain. A few hours later, a host on the IT network starts a scan toward the OT network on Modbus ports. On its own, this second event might look like the benign behavior of some misconfigured monitoring script. But correlated with the earlier phishing event, in the same timeframe and from the same source subnet, it becomes a strong signal of lateral movement toward OT.

Correlation requires that both events be in the SIEM at the same time, with consistent timestamps and common identifiers (at least the source IP address) that allow the correlation engine to link them. Without OT visibility in the SIEM, the second event does not exist, the attack chain stays invisible and the IT analyst sees nothing anomalous.

This scenario is not theoretical: most of the significant attacks on industrial environments in recent years have followed the IT-OT chain, starting from email, VPN or the supply chain and then moving toward control systems. Detecting this movement requires integrated data.

Training SOC Analysts on OT

Bringing OT events into the SIEM is the technical part. The organizational part is ensuring that SOC analysts know what to do with them.

An IT SOC analyst who sees, for the first time, an alert reading "Modbus function code 6 (Write Single Register) from a non-whitelisted host toward a PLC in zone 3" lacks the context to understand its severity. They might close it as noise, or escalate it without knowing to whom. The training required is not a full course in industrial automation: it is enough understanding of the OT context to perform triage.

The fundamental elements a SOC analyst should have in order to handle OT alerts:

A map of the OT zones and their criticality. Which zone contains the systems most critical to production continuity? An alert involving the supervision zone of the main process has a different priority from one involving the technical office network. The map must be available in the SIEM or in a reference document accessible during triage.

A list of OT protocols and their basic meaning. There is no need to know the Modbus protocol in detail, but it is essential to understand that a write to a control register on a production PLC is an action that can change the behavior of the physical process. This awareness changes the priority of the alert.

Operational contacts for OT escalation. When a SOC analyst identifies an OT alert they cannot classify, they must know whom to turn to: the OT manager, the CISO with an industrial background, the control systems vendor. The escalation path must be documented in the playbooks.

Playbooks specific to the most frequent OT alert types. Not generic IT playbooks adapted on the fly, but playbooks written specifically for the OT context: what to do when a new unauthorized device appears, what to do when a remote access session starts after hours, what to do when scanning traffic toward the OT network is detected.

The Practical Challenges of Integration

Bringing OT monitoring into the SIEM is technically feasible in most environments, but some practical challenges deserve attention.

Network connectivity between OT and the SIEM: the OT collector that aggregates the events must have connectivity toward the SIEM, which is often in IT or in the cloud. This connectivity must pass through the industrial DMZ with precise rules, not open a direct connection between OT and IT.

Event volume and SIEM licensing costs: some SIEMs scale their cost with the volume of ingested events. Before bringing all OT traffic into the SIEM, you need to estimate the volume and filter properly to avoid unexpected costs.

Alert latency: if the SIEM is cloud-hosted and the OT collector is on-premise, the path of the event (OT collector -> DMZ -> internet -> cloud SIEM -> analyst) can introduce latency. For most OT alerts this latency is acceptable (a matter of seconds or minutes), but you should verify that it does not exceed the SLA thresholds defined for critical alerts.

OT log retention: some compliance requirements (NIS2, IEC 62443) require that security logs be kept for defined periods. The SIEM must be configured with retention policies appropriate for OT events, which may differ in volume and structure from IT events.

OT-SIEM integration is not a project to complete in a weekend, but it is one of the investments that delivers a multiplier effect on existing capabilities: a SOC that was partially blind becomes able to see the organization's entire attack surface.

The MON5 Angle

A SOC blind to the OT half of the company needs, first of all, a reliable data source. MON5 was built for this role: passive, out-of-band NDR that decodes native OT protocols (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) and generates events that are already filtered and contextualized, ready for IT-OT correlation in the existing SIEM.

Its multi-tenant, multi-site architecture also fits MSSP-managed SOCs and industrial groups with multiple plants. To find out which OT events your SOC is missing today, the starting point is an OT assessment.