Building a SOC for OT Environments: Requirements, Tools, and Operational Metrics

Why the IT SOC Cannot See OT

A well-equipped IT SOC has visibility into email, endpoints, networks, web applications, authentication, and user behavior. It has tools to correlate events from different sources, analysts trained to recognize attack patterns, and playbooks for the most common incident types.

But this SOC is blind to OT environments. Not because analysts are incompetent — because the visibility simply is not there. OT devices do not send logs to the centralized SIEM. Modbus traffic is not monitored. Changes to PLC logic do not generate alerts. An attacker moving through the OT network is completely invisible to the IT SOC.

The gap is not strictly technical — it is architectural. OT networks were not designed to generate security telemetry. Field devices have no endpoint agents. Industrial protocols have no native application logs. Building OT visibility requires a different approach from the one used for IT.

Technical Requirements: Sensors, Collectors, SIEM Integration

OT visibility is built primarily through passive network traffic monitoring: positioning sensors (network taps or SPAN ports) in key zones of the OT network and capturing all traffic for analysis.

Specialized OT network sensors have capabilities that generic IT sensors lack:

• Industrial protocol decoding: understanding the content of a Modbus, OPC UA, DNP3, PROFINET, or EtherNet/IP session — not just the underlying TCP connections.
• Passive asset identification: recognizing OT devices from their traffic patterns, extracting software and firmware versions without actively querying devices (which could disrupt processes).
• Behavioral baseline: establishing the normal communication profile for each device and detecting deviations.
• CVE correlation for OT: associating identified devices with known vulnerabilities from the ICS-CERT and CISA databases.

Data collected from OT sensors must be normalized and sent to the SIEM (or a dedicated OT monitoring platform integrated with the SIEM) for correlation with IT events. An attacker who starts in IT and moves toward OT leaves traces on both networks; only integrated visibility allows reconstructing the full chain.

Skills: The Right Person for an OT SOC

An OT SOC requires a different analyst profile than an IT SOC. Taking an IT analyst and giving them an OT course is not sufficient — the mindset must change.

Fundamental competencies for an OT SOC analyst:

Knowledge of industrial control systems: understanding what a PLC is, how a SCADA system works, what an RTU does, how a field network operates. Without this foundation, OT alerts are incomprehensible.

Understanding of industrial processes: knowing that an "anomalous write to PLC register" alert on a chemical dosing system is potentially critical, while the same alert type on a lighting system has different priority. Operational context is everything.

Knowledge of OT protocols: recognizing normal vs. anomalous Modbus traffic, understanding what a Security Policy change in OPC UA means, interpreting DNP3 function codes.

Tolerance for uncertainty: in OT, many alerts have benign causes — routine maintenance operations, legacy behavior of dated systems. The OT analyst must be able to distinguish signal from noise without raising so many false positives that attention becomes saturated.

The most common solution in mid-sized organizations is the hybrid SOC: traditional IT analysts handling primary triage, with escalation to OT specialists for alerts requiring specific industrial context.

Specific Playbooks: OT Alerts vs. IT Alerts

OT alert response playbooks cannot be copies of IT ones. The appropriate actions are different, and as discussed in the OT incident response article, the IT "isolate and shut down" often becomes "monitor and coordinate with operations" in OT.

Examples of specific OT playbooks:

Alert: PLC logic modification outside maintenance windows

1. Verify whether an unscheduled maintenance activity is in progress (call the operations manager)
2. If no operational justification: isolate the system from remote access and alert the incident response team
3. Preserve the modification log and the pre-modification configuration
4. Do not restart or restore without preliminary forensic analysis

Alert: new device appearing on the OT network

1. Identify the device — is it the result of planned maintenance? Is it a temporary vendor device?
2. If unauthorized: block communications to/from the device at the firewall level
3. Investigate the physical connection point

Alert: communication toward external IP from an OT device

1. Verify whether it is a legitimate vendor telemetry channel
2. Analyze traffic content
3. If unjustified: block the destination at the firewall level and initiate investigation

Metrics: Measuring Industrial SOC Effectiveness

The OT SOC must be measured, but standard IT metrics do not all apply. The number of alerts handled per day is not meaningful if most are false positives.

Relevant metrics for an OT SOC:

Time to Detect (TTD): how much time passes from when anomalous behavior first becomes detectable to when an analyst examines it. In OT, where APTs move slowly, detecting their presence in the first hours has enormous impact.

False positive rate: the percentage of alerts that turn out to be non-malicious after triage. A high rate indicates poorly calibrated baselines or detection rules not adapted to the specific environment.

Critical asset coverage: what percentage of critical OT assets is covered by monitoring? Critical assets without visibility are known blind spots.

Rule update time: how quickly are detection rules created for new OT-specific threats (new CVEs, new APT campaigns targeting industrial environments)?

Detection exercises: how frequently are exercises conducted where the OT SOC must detect simulated attack behaviors? This is the only way to verify that detection capabilities actually work before they are needed.

A mature OT SOC is not built in a few months — it requires time to calibrate baselines, build the environment-specific knowledge base, and train personnel. But every step toward OT visibility is an improvement in security posture compared to the total blindness that still characterizes many industrial organizations.

The MON5 Angle

An OT-blind SOC is not fixed by asking more logs from devices that do not produce them — you need to generate the missing telemetry. MON5's PROTECT phase does this with out-of-band passive NDR on native OT protocols (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP), behavioral baselines, and ML anomaly detection, with no agents on field devices.

Data arrives normalized and ready for correlation with IT events, so analysts work on alerts with industrial context rather than raw packets. The path is modular and starts with visibility: the first step is an OT assessment that captures assets and traffic in your plant.