How sFlow Monitoring Detects Lateral Movement in OT Networks

Almost every serious OT incident of the last decade shares the same middle chapter. The initial access is rarely exotic: a phished credential, an exposed VPN appliance, a contractor laptop. The damage happens later, when the attacker moves sideways, from the IT network into the industrial zone, from an engineering workstation to a PLC, from one process cell to the next. That phase is called lateral movement, and it is the phase most OT networks are structurally blind to.

Firewalls and perimeter tools watch traffic crossing zone boundaries. But once an attacker is inside a zone, the traffic that matters is east-west: host to host, switch to switch, often never touching a firewall at all. In the Triton attack on a Saudi petrochemical plant, the attackers spent months traversing from the corporate network to the safety instrumented system. In the 2021 Oldsmar water treatment intrusion, the operator only noticed because a mouse cursor moved on screen. Neither environment lacked perimeter security. Both lacked visibility into what was moving inside.

This is the problem flow telemetry was built for.

What sFlow Actually Gives You

sFlow is a sampling technology built into most managed switches. Instead of capturing every packet, the switch samples packets at a configured rate (say, 1 in 512) and exports compact records describing who talked to whom: source and destination addresses, ports, protocols, byte and packet counts, and interface information.

Three properties make it unusually well suited to OT environments:

It is passive and agentless. Nothing is installed on the PLCs, RTUs, or HMIs. The switch does the work. In environments where a 15-year-old controller cannot tolerate an active scan, let alone an endpoint agent, this matters more than any feature list.

It sees east-west traffic. Because the telemetry comes from the access and distribution switches themselves, sFlow observes traffic between two hosts on the same VLAN, traffic that never reaches a firewall, an IDS on a perimeter tap, or a cloud proxy.

It scales cheaply. Sampled flow records are tiny compared to full packet capture. A single collector can watch an entire plant floor without dedicated capture hardware on every segment.

The Physics of Lateral Movement

Here is the insight that makes flow-based detection work: industrial devices are creatures of habit, and lateral movement is not.

A PLC on a packaging line talks to a small, fixed set of peers: its HMI, its engineering workstation during maintenance windows, maybe a historian. It uses the same protocols on the same ports, in the same direction, with traffic volumes that follow the production schedule. Week after week, the communication graph of a healthy OT network barely changes. This is fundamentally different from IT networks, where users browse, update, and roam.

An attacker moving laterally cannot help but violate that graph. Consider what lateral movement actually looks like on the wire:

New peer relationships. An engineering workstation suddenly opens connections to twelve PLCs it has never spoken to. Each individual connection looks legitimate. The pattern, a device expanding its peer set far beyond its baseline, is the signature.

Scanning and enumeration. Before moving, attackers map. A host probing sequential IP addresses on port 502 (Modbus) or 44818 (EtherNet/IP) produces a distinctive fan-out: many destinations, few packets each, high failure rate. Sampled flow data captures this shape clearly even at aggressive sampling rates, because scans generate many flows, not many packets per flow.

Protocol misuse by role. Devices in OT networks have roles, and roles imply protocols. An HMI speaking SSH to a historian, a PLC initiating outbound HTTPS, a workstation in the DMZ opening SMB sessions toward the control zone: each is a protocol appearing where the role says it should not.

Volume and timing anomalies. Data staging before exfiltration shows up as sustained transfer volumes far above a device's baseline. Command-and-control beaconing shows up as small, metronomically regular flows to a single destination. Activity at 03:00 on a line that runs one shift is its own signal.

None of these detections require decrypting anything or parsing a proprietary protocol. They fall out of the flow metadata, compared against a behavioral baseline.

From Flow Records to Detection: What the Baseline Requires

Raw flow records are not detections. The collector receiving them has to answer a harder question: is this communication normal for this specific device in this specific plant? That requires three layers of work.

Device identity. A flow record says 10.20.4.17 talked to 10.20.4.55. Detection requires knowing that the first is a Siemens S7-1500 PLC and the second is an engineering workstation, because the same flow is routine between one pair of roles and alarming between another. Passive fingerprinting from traffic characteristics builds this inventory without touching the devices.

Behavioral baselines per device. Peer sets, protocol mix, traffic volumes, timing patterns, and connection durations, learned over days or weeks of observation. The baseline is the definition of normal against which lateral movement stands out.

Anomaly scoring with context. A new peer relationship involving a safety controller is not the same severity as one involving a printer. Scoring that weights device criticality and protocol sensitivity is what separates an actionable alert queue from a noise generator.

Practical Deployment in a Plant Network

Getting from zero to useful lateral movement detection is less invasive than most teams expect:

1. Enable sFlow on managed switches at the cell/area and distribution layers. Most industrial Ethernet switches from the major vendors support it or NetFlow/IPFIX equivalents. Start with a moderate sampling rate; 1-in-256 to 1-in-1024 is typical.
2. Point exports at a collector inside the OT DMZ or site network. Flow records are compact, so bandwidth impact on the control network is negligible.
3. Let the baseline learn before you alert. Two to four weeks of observation covering at least one full production cycle, including a maintenance window, prevents the classic false-positive wave.
4. Pair it with a SPAN/mirror feed where depth matters. Flow telemetry gives breadth across every switch port cheaply; DPI on mirrored traffic gives depth on the segments that carry your critical process communication. The combination is what catches both the movement and the payload.

The per-site economics are worth noting: because the switches you already own generate the telemetry, coverage cost scales with sites, not with device count. A plant with 2,000 devices and a plant with 200 need the same collector footprint.

What This Looks Like When It Works

Return to the Triton scenario: months of quiet traversal from IT toward the safety system. Every step of that journey is a flow event. The initial pivot host contacting the OT DMZ. The remote access tool beaconing outward. The enumeration of the controller subnet. The first connection from a compromised workstation to the safety controllers, a peer relationship that had never existed before.

A perimeter tool sees, at best, one of those steps. A behavioral system watching east-west flow telemetry sees a device stepping outside its history four separate times, with weeks of opportunity to catch it before the final stage.

The Bottom Line

Lateral movement is where intrusions become incidents, and it happens in the east-west traffic your perimeter stack does not see. sFlow and its flow-telemetry cousins turn the switches you already own into a plant-wide sensor grid: passive, agentless, and cheap to scale. Combined with per-device behavioral baselines and DPI where depth is needed, flow monitoring gives OT defenders what they have historically lacked, which is time: the ability to see an attacker's second move instead of their last one.