Building an OT SOC: Monitoring Industrial Networks Without Opening Them

01Key takeaways

1. 01

   An OT SOC monitors industrial networks under safety and availability constraints that make IT SOC habits like active scanning and agents risky or unworkable.

2. 02

   Visibility should come mostly from passive sources: SPAN or TAP traffic capture, protocol-aware analysis, and logs the devices already produce.

3. 03

   The monitoring path itself is an attack surface. Wherever possible, export telemetry one-way so analytics and the SOC cannot send traffic back into the protected zone.

4. 04

   Detection should be ICS-specific, mapped to MITRE ATT&CK for ICS and framed by IEC 62443 zones and conduits, not copied from IT detection content.

5. 05

   A data diode or unidirectional gateway is one control among many. It reduces a specific risk: that the log and telemetry pipeline becomes a route back into OT.

02What an OT SOC is and how it differs from an IT SOC

An OT SOC is a security operations function dedicated to operational technology environments: industrial control systems, SCADA, distributed control systems, safety instrumented systems and the networks that connect them. Its job is the same as any SOC at a high level. It builds visibility, detects threats, triages alerts and supports incident response. What changes is everything underneath that summary.

In IT, the priority order is usually confidentiality, integrity, then availability. In OT, that order often inverts: availability and safety come first, because the system controls physical processes that can hurt people or stop production. A SOC analyst cannot quarantine a controller that is regulating pressure in a pipeline the way they might isolate a laptop. The response playbooks, the tooling and the acceptable techniques all differ.

IT SOC instinct

Deploy endpoint agents, scan the network for assets, patch quickly, and isolate compromised hosts on demand.

OT SOC reality

Many devices cannot run agents, active scans can crash legacy equipment, patch windows are rare, and isolation can trip a process.

03Why monitoring industrial networks is now non-negotiable

OT used to rely on obscurity and isolation. That assumption no longer holds. IT and OT networks are increasingly converged, remote access expanded sharply over the last decade, and threat actors have built ICS-specific capability. Malware families and incidents such as Stuxnet, the 2015 and 2016 Ukraine grid attacks, TRITON targeting a safety instrumented system, and the INDUSTROYER and PIPEDREAM toolkits show that adversaries can and do operate inside industrial networks.

Detection in OT is also harder to outsource to luck. A compromised engineering workstation can issue legitimate-looking commands. A malicious logic download to a PLC may look like normal engineering activity. Without monitoring that understands industrial protocols and normal process behavior, these actions pass unnoticed until something physical breaks.

The goal of an OT SOC is not to bolt IT tooling onto the plant. It is to detect adversary behavior in a place where the first sign of compromise may be a change to a setpoint, a logic download, or a new device speaking Modbus where none should exist.

04Building visibility without touching the process

The foundation of an OT SOC is passive visibility. Instead of probing devices, you observe the traffic they already generate. The most common method is to mirror traffic from switches using SPAN ports, or to install network TAPs on key links, and feed that copy to a passive monitoring sensor. The sensor never injects packets onto the production network, so it cannot disturb the process it is watching.

• Network TAPs on critical links, including the IT/OT boundary, control-network uplinks and links to engineering workstations.
• SPAN or mirror sessions on managed switches where TAPs are impractical, accepting that SPAN can drop packets under load.
• Protocol-aware deep packet inspection for industrial protocols such as Modbus/TCP, DNP3, EtherNet/IP, OPC UA, PROFINET, IEC 60870-5-104 and IEC 61850 GOOSE/MMS.
• Asset discovery derived from observed traffic, so an inventory is built without ever scanning a device.
• Existing device and system logs from historians, HMIs, engineering tools, firewalls and jump hosts, collected rather than generated.

Passive monitoring gives you two things at once: an asset inventory and a behavioral baseline. Because industrial traffic is far more repetitive than enterprise traffic, deviations from that baseline, such as a new IP, an unexpected function code, or a logic download outside a maintenance window, are unusually strong signals.

05Reference architecture: where the SOC sits relative to the plant

A well-structured OT SOC architecture follows the layered model described in IEC 62443 and the Purdue reference model. Sensors live down in the cell, area and supervisory levels (roughly Purdue Levels 1 to 3), close to the equipment they observe. Aggregation, analytics, the SIEM and analyst workflows live up in IT or a dedicated security zone (Level 3.5 DMZ and above).

The critical design decision is how telemetry crosses from the protected OT zone up to the SOC. A conventional approach forwards logs over a firewall conduit, which keeps a bidirectional path alive even if policy restricts it. A stronger approach, where the use case allows, is to push telemetry outward through a one-way boundary so the SOC, the SIEM and the analytics platform have no network route back down into the control network.

Collection tier

Passive sensors and log shippers inside the OT zones, capturing traffic and device logs at Purdue Levels 1 to 3.

Transfer tier

The boundary that moves telemetry from OT to the SOC: a firewall conduit, a unidirectional gateway, or a data diode with supporting software.

Analysis tier

SIEM, detection content, dashboards, case management and analyst workflows in an IT or security zone.

06Why the monitoring path should be one-way wherever possible

Monitoring creates a paradox. To watch the OT network you must move data out of it, and any path out can become a path in. Centralized log servers, SIEM collectors and analytics platforms are attractive targets precisely because they touch many systems. If that pipeline is bidirectional, compromising the upstream platform can hand an attacker a route straight into the control network.

A one-way design removes that route. Telemetry, packet metadata, alerts and historian extracts are published outward through a data diode or unidirectional gateway. The receiving side gets everything it needs to detect and investigate, but it has no return path to query, command or reach back into the protected zone. The act of monitoring no longer enlarges the attack surface it is meant to protect.

A data diode is one control among many, not a SOC by itself. Its specific contribution is narrow and valuable: it ensures the log and telemetry pipeline cannot be turned around and used as a way back into OT.

07Detection content: think in MITRE ATT&CK for ICS

IT detection content does not transfer cleanly to OT. An OT SOC needs use cases built around industrial adversary behavior. MITRE ATT&CK for ICS provides the shared vocabulary: tactics and techniques observed in real ICS attacks, from initial access and lateral movement through to impair process control and damage to property.

• Unauthorized engineering activity, such as a PLC program download or firmware update outside an approved maintenance window (ATT&CK for ICS techniques like Program Download and Modify Controller Tasking).
• New or unexpected hosts appearing on a control segment, or a device suddenly using a protocol or function code it never used before.
• Manipulation of control logic or setpoints, and unexpected use of writes where a system normally only reads.
• Loss of view or denial of view, where HMI or historian data stops updating or diverges from field reality.
• Connections crossing zone boundaries that violate the documented IEC 62443 conduit policy.

Map every detection use case to an ATT&CK for ICS technique and to the affected zone. That mapping gives analysts context, helps prioritize coverage gaps, and produces a defensible story about what the SOC can and cannot currently see.

08Standards and compliance: framing the work

An OT SOC does not exist in a vacuum. Several frameworks define both the architecture and the expectations regulators and auditors will apply. Treat them as design inputs, not paperwork to retrofit afterward.

NIST SP 800-82 Rev. 3

Guide to OT security; sets out monitoring, segmentation and detection guidance tailored to control systems.

ISA/IEC 62443

Defines zones and conduits, security levels, and the foundational requirements (including system integrity and timely response to events) that a SOC helps satisfy.

MITRE ATT&CK for ICS

A knowledge base of adversary tactics and techniques used to build and assess OT detection coverage.

NERC CIP

For the North American bulk electric system, mandates security monitoring, logging and event response for high- and medium-impact systems (CIP-007, CIP-008).

Mapping detection use cases and architecture decisions to these frameworks does double duty. It improves the security outcome and it produces the evidence auditors expect: which zones are monitored, how events are logged, how long data is retained, and how the SOC responds when something fires.

09Common pitfalls when standing up an OT SOC

Most failed OT SOC programs do not fail on tooling. They fail on assumptions imported from IT, on alert noise, or on a monitoring design that quietly reintroduces the risk it was meant to remove.

• Running active vulnerability scans against fragile devices and causing the outage you were trying to prevent.
• Reusing IT detection content, then drowning analysts in false positives that have no OT meaning.
• Forwarding logs over a bidirectional conduit and leaving the SIEM as a soft route back into the control network.
• Treating the passive sensor management plane as trusted, so its update or admin channel becomes an inbound path into OT.
• Building dashboards without a tuned baseline, so genuine anomalies are buried under normal process variation.
• Staffing the SOC entirely with IT analysts who lack process and controls context, with no path to escalate to engineering.

The recurring theme is reachability. A SOC adds value only if it does not become the most connected, most trusted, and therefore most dangerous system touching the plant.

10A staged rollout that earns trust

You do not build an OT SOC in one step. A staged rollout lets you prove value, tune detection, and keep operations confident that monitoring is not endangering production.

• Start with passive visibility on the highest-consequence segment, usually the IT/OT boundary and the control network uplink.
• Build the asset inventory and behavioral baseline from observed traffic before writing any detection rules.
• Establish one-way export of logs and telemetry to the SOC, so the analysis tier never gains a return path into OT.
• Add ICS-specific detection use cases mapped to MITRE ATT&CK for ICS, tuned against the baseline.
• Define joint response playbooks with operations and engineering, including who can authorize what action on which asset.
• Expand sensor coverage zone by zone, mapping each addition to IEC 62443 conduits and documenting what is now visible.

Sequence matters: visibility before detection, detection before automation, and a one-way transfer path before you centralize everything in a SIEM that an attacker would love to own.

11Closing thought

An OT SOC is how an organization moves from hoping its industrial networks are quiet to actually knowing what they are doing. The constraints are real: you cannot scan freely, you cannot agent everything, and you cannot trade availability for visibility.

The cleanest way through those constraints is to watch passively and export one-way. Collect what the network already tells you, send it outward through a boundary that cannot be turned around, and build detection that speaks the language of control systems. Done that way, monitoring industrial networks makes them safer without opening them.

FAQFrequently asked questions

SRCSources of record