Why Your Factory Floor Is the Softest Target in Your Network

Most security teams I talk to have reasonable IT hygiene: EDR on endpoints, a SIEM ingesting Windows event logs, maybe a WAF in front of the web apps. Then I ask them what’s running on the factory floor and the answer is usually some variation of "Siemens S7s, a Mitsubishi SCADA, and honestly we’re not totally sure what else."

That gap — between "we have a SOC" and "we have visibility into our OT environment" — is where the real risk lives.

The Architecture Problem

The Purdue Model (ISA-99) was designed to keep OT and IT separated. In theory: Level 0–2 is the physical process (PLCs, sensors, actuators), Level 3 is manufacturing operations (MES, historians), and Level 4+ is enterprise IT. A DMZ sits between 3 and 4. Nothing from the internet touches a PLC.

In practice, that boundary eroded over the last 15 years because of one word: remote access.

Plant engineers needed to SSH into historians from home. Vendors needed VPN access to update firmware on their own equipment. Management wanted live OEE dashboards in the ERP. Each of these was a reasonable business request. Collectively, they punched the Purdue Model full of holes.

What you’re left with is a factory network where:

• PLCs run firmware from 2009 with no authentication on Modbus TCP
• The historian runs Windows Server 2012 R2 (EOL, unpatched, lives on both L3 and L4)
• A vendor VPN concentrator sits directly on the OT segment with credentials the vendor set and nobody rotated
• Operators use the same workstation to check email and run the HMI

This is not a hypothetical. This is almost every factory I’ve looked at.

What Attackers Actually Do

OT attacks rarely start on the factory floor. They start exactly where IT attacks start — phishing, exposed RDP, a compromised vendor account — and then pivot.

The classic path:

1. Compromise an IT endpoint (Windows workstation, mail server)
2. Move laterally to the historian or engineering workstation — the bridge machine
3. From there, enumerate the OT segment: scan for Modbus on port 502, EtherNet/IP on 44818, OPC-DA over DCOM
4. Map the process: what does this PLC control? What’s the impact of changing a setpoint?
5. Either deploy ransomware (encrypt the historian, demand payment) or manipulate the process directly

Stuxnet was step 5. Most attackers today stop at step 4 and go ransomware because it’s lower risk and faster payout. But the capability for step 5 exists and the barrier is lower than most plant managers realize.

Why Standard IT Security Tools Miss This

Your EDR doesn’t run on a PLC. Your SIEM probably isn’t parsing Modbus function codes. Your vulnerability scanner will crash a PLC if you point it at one — active scanning sends probe packets that the PLC’s TCP stack can’t handle.

OT requires a different approach:

Passive monitoring only. You tap the network (SPAN port or network TAP) and observe traffic without generating any. Zeek is good at this. Some commercial tools (Claroty, Dragos, Nozomi) do it with OT protocol decoders out of the box.

Protocol-aware detection. Normal Modbus traffic in a running factory is highly repetitive — the SCADA polls the same coils at the same interval, all day. An anomaly looks like: a new source IP sending Modbus WRITE MULTIPLE REGISTERS at 2am, or a function code (FC 8, diagnostics) that never appears in normal operations suddenly appearing. These aren’t signature-based detections; they’re behavioral baselines.

Asset-centric alerting. In IT you alert on users. In OT you alert on assets — specific IP/MAC combinations tied to physical equipment. "PLC-04 received an unsolicited connection from 10.0.1.88" is actionable. "Anomalous Modbus traffic detected" is not.

A Practical Starting Point with Wazuh

If you’re already running Wazuh for IT, you can extend it into OT without buying a dedicated OT platform. The coverage won’t be as deep as Dragos, but for most Thai factories the gap right now isn’t "we need enterprise OT XDR" — it’s "we have zero visibility."

Here’s a practical starting architecture:

flowchart TD
  subgraph OT["OT Network (Level 2/3)"]
    PLC1["PLC (Modbus TCP)"]
    PLC2["PLC (EtherNet/IP)"]
    HMI["HMI Workstation"]
    SCADA["SCADA / Historian"]
    OT_SW["OT Switch (SPAN port)"]

    PLC1 --> OT_SW
    PLC2 --> OT_SW
    HMI --> OT_SW
    SCADA --> OT_SW
  end

  subgraph SENSOR["Passive Sensor (DMZ)"]
    TAP["Network TAP"]
    ZEEK["Zeek Sensor\n(modbus.log / conn.log)"]
    AGENT["Wazuh Agent"]

    TAP --> ZEEK
    ZEEK --> AGENT
  end

  subgraph SOC["SOC Backend (IT Network)"]
    WAZUH["Wazuh Manager\n(OT Detection Rules)"]
    OS["OpenSearch / Kibana\n(OT Dashboard)"]
    IRIS["DFIR-IRIS\n(Case Management)"]
    PD["PagerDuty\n(Alerting)"]

    WAZUH --> OS
    WAZUH --> IRIS
    WAZUH --> PD
  end

  OT_SW -->|"SPAN (read-only)"| TAP
  AGENT -->|"Encrypted log shipping"| WAZUH
  SCADA ---|"Bridge host\n(monitored)"| IT_FW

  IT_FW["Firewall / DMZ"]
  IT_FW --> WAZUH

Key Wazuh rules to write first:

• Alert on any Modbus FC 5 (Write Single Coil) or FC 15 (Write Multiple Coils) outside maintenance windows
• Alert on new source IPs communicating with known PLC addresses
• Alert on historian bridging both OT and IT subnets receiving connections from IT-side hosts after hours
• Alert on EtherNet/IP List Identity broadcasts (common recon step)

The Wazuh ruleset for Modbus isn’t in the default distribution — you’ll need to write custom decoders. The Modbus TCP payload starts at byte 7 of the TCP stream; function code is the first byte of the PDU. Zeek’s modbus.log gives you this parsed already.

The Hardest Part: IR Without Stopping the Line

OT incident response is constrained in ways IT IR isn’t. You can’t isolate a PLC mid-production run. You can’t reimage an HMI while it’s running the process. Availability beats confidentiality and integrity in OT — that’s the inverse of enterprise IT.

This means your IR playbook needs to be written before an incident, in collaboration with operations, not just security. For each asset: what is the blast radius of isolation? Who authorizes a controlled shutdown? What’s the manual fallback if the SCADA goes dark?

These are operational questions, not technical ones. Getting them answered requires sitting down with the plant manager and production engineer, not just the IT team.

Where to Start

If you’re an IT/OT engineer trying to build a case internally, the lowest-friction entry point is a passive OT asset discovery exercise. No agents, no active scanning, no changes to the production network. Just a TAP on the OT switch and Zeek running for two weeks.

At the end you have:

• A full asset inventory (device type, IP, MAC, protocol, vendor if identifiable)
• A communication matrix (who talks to who, on what protocol, how often)
• An anomaly baseline

That output alone is usually enough to get budget approved for the next phase. Most plant managers don’t know what’s on their OT network. Showing them — visually, with a network map — makes the risk concrete in a way that a threat report never does.

Final Thought

OT security isn’t exotic anymore. The tooling is mature enough to deploy without a massive budget, and the threat is real enough that "we’ll get to it later" is no longer a defensible position. The factories that get hit with OT-targeted ransomware in the next 24 months will mostly be ones that knew they had a gap and didn’t act.

The good news: the baseline is low. Any visibility is better than none. You don’t have to boil the ocean — start with a passive tap, a Zeek sensor, and a handful of well-written Wazuh rules. That alone puts you ahead of 80% of the industrial sites in Southeast Asia.

Simplico Co., Ltd. builds OT/IT security infrastructure for manufacturing and critical infrastructure clients across Thailand and Southeast Asia. If you’re looking at your OT environment and want a second opinion, get in touch.