East-west segmentation inside OT on your firewall

To check east-west traffic between OT cells on a firewall, first make sure each cell is its own zone on its own firewall interface or VLAN subinterface, because the firewall only sees traffic that crosses it. Then read the rules between cells and levels against a traffic log that covers shifts, batch runs and maintenance: list the flows each conduit carries, and question paths that skip a level, remote-access and file-sharing tools onto Level 2 and Level 1, cleartext transfers, and broad any-host or any-application rules. Tighten with rules that log before anything is blocked.

North-south traffic crosses between IT and OT. East-west traffic stays inside OT: an engineering workstation reaching a PLC, an HMI in one cell polling a controller in another, a historian collecting from every line. An intruder or malware that reaches one OT host moves east-west from there, so what the rules inside OT allow decides how far it gets.

A common claim is that firewalls can’t segment OT east-west. Part of that is true and part is not, and the difference decides where the firewall you already own does the job.

East-west firewall review checklist

1. Each cell is its own zone on its own firewall interface. Traffic inside one zone never reaches the firewall.
2. No path skips a level, such as Level 3 straight to Level 1. NIST SP 800-82r3 section 5.2.3.1.
3. No remote-desktop, file-sharing or remote-support tools onto Level 2 or Level 1 without a documented reason. IEC 62443-3-3 SR 5.2 and SR 7.7.
4. No cleartext transfers of credentials, programs or recipes between zones. IEC 62443-3-3 SR 4.1.
5. Rules between cells name hosts and applications, not whole zones and “any”. IEC 62443-3-3 SR 5.1 and SR 5.2.
6. Safety systems have their own boundary. NIST SP 800-82r3 section 5.3.1.
7. Paths around the firewall are on the zone map: cellular modems, vendor boxes, dual-homed workstations.
8. New boundaries inside OT start by logging, not blocking. NIST SP 800-82r3 section 6.2.1.3 suggests recording traffic between segments to learn which flows to authorize.

What the firewall can control

A firewall decides on traffic that passes through it. If each OT zone sits on its own firewall interface or VLAN subinterface, every session between zones crosses the firewall and meets a rule. That covers the conduits that matter most inside OT:

• Between Purdue levels. Operations (L3) to supervisory (L2), and supervisory to basic control (L1).
• Between cells or lines. One production cell’s zone to another’s, where the process needs them to talk at all.
• From shared OT services. Historians, engineering workstations and OT domain controllers reaching into the cells.

Rules on those conduits can name the hosts, the direction and the protocol. Every firewall can do that by port. Where the firewall’s application identification is licensed and turned on, rules can also name industrial protocols such as Modbus/TCP, EtherNet/IP or S7comm as applications.

What the firewall can’t see

• Traffic inside one zone. Two hosts in the same zone, or on the same switch, talk without the firewall. A cell whose HMI, PLCs and I/O share a zone is one segment as far as the firewall goes. That is usually fine: HMI to PLC and PLC to I/O inside a cell is the process itself.
• Zones that were never split. If OT is one big zone, nothing east-west crosses the firewall. See flat OT networks.
• Paths around it. A cellular modem, a vendor VPN box or a dual-homed workstation in a cell is a conduit the firewall never sees. Draw it on the zone map anyway.

Safety systems deserve their own boundary. NIST SP 800-82r3 (section 5.3.1) asks organizations to consider segmenting and isolating safety systems from other OT systems, and notes that safety may call for physical rather than logical separation.

What the standards ask inside OT

NIST SP 800-82r3 section 5.2.3.1 asks for firewall rules that allow connections only between adjacent levels, tiers or zones, which applies inside OT as much as at the IT boundary. A Level 3 workstation that reaches a Level 1 PLC directly skips the supervisory boundary in between. The NIST SP 800-82r3 guide has the detail.

IEC 62443-3-3 SR 5.1 (network segmentation) and SR 5.2 (zone boundary protection) apply to every zone boundary, not just the one with IT. IEC 62443-3-2 leaves the zone design and each zone’s target security level to the asset owner. The IEC 62443 guide covers both. The Purdue model gives the common words for which hops are adjacent; it does not require any of them.

What to look for in the rules inside OT

• Skip-level conduits. L3 to L1, or L3 to L0, with no supervisory boundary between. The most common is an engineering workstation reaching PLCs directly.
• Remote and file-sharing tools onto L2 or L1. SSH, RDP, SMB and VNC into supervisory or control networks.
• Applications that don’t fit the hop. A protocol on a conduit that the zone design doesn’t expect there.
• Cleartext transfers across zones. Telnet, FTP, HTTP or TFTP carrying credentials, programs or recipes between OT zones.
• Broad rules between cells. Any-application or any-host rules between cells, often left from commissioning.

Tighten it without stopping a line

East-west rules inside OT carry the process, so the order of work matters more than at the IT boundary.

1. Collect a long enough traffic log. Cover shifts, batch runs, changeovers and maintenance. A rule with no hits this week can still be the one a quarterly job needs.
2. Start with the paths that should not exist. Skip-level paths and remote tools onto L2 and L1 usually have a better route: controller work from an engineering workstation in the cell’s supervisory zone, and remote sessions through the IDMZ jump host to a Level 3 host.
3. Log before you block. Between cells and levels inside OT, start with allow-and-log rules that name what the log showed. Tighten only once the conduit carries nothing unexpected.
4. Keep the control paths. HMI to PLC and PLC to I/O inside a cell stay allowed. Never remove cyclic I/O or a safety path outside a planned window with a rollback.
5. Recertify what has an owner. A rule an engineer needs, such as programming access to a PLC, gets a named owner, a reason and a review date instead of a silent delete.

How SegAudit reports east-west paths

SegAudit places each zone on the Purdue level you confirm and reads the firewall rules and traffic log against those levels. Inside OT, paths that skip a level become findings with the sessions, hosts and allowing rule behind them.

In the Northline sample (a made-up three-site company that ships with SegAudit), rule allow-eng-to-plc lets engineering workstations at Level 3 reach PLCs at Level 1. The engine reports “Skip-level conduit L3 → L1 · 15 sessions” (high) across the three sites, and “ssh from L3 onto L1 · 10 sessions” on the same rule. Its recommendation reads: “Break the path into adjacent hops with inspection at each zone boundary. If a skip is required, document it as an IEC 62443 conduit with compensating controls — do not leave a raw allow.” Because the rule carries a named user, the periodic rule review marks it recertify rather than removing it.

Lock down, which proposes rules for a firewall that still allows everything, writes no rule inside OT and never blocks traffic between OT subnets. It lists the flows the firewall logged between them, for the site to review.

To see what SegAudit catches in one of your own exports, run the free Quick check. The sample deliverable shows the full report.

Common questions

Do we need a separate product for east-west segmentation in OT?

Not for traffic that crosses zones on the firewall you have: rules there can name hosts, direction and protocol. A firewall can’t control traffic that never reaches it, such as traffic inside one zone or one switch, so splitting zones comes first.

Should cell-to-cell traffic be blocked?

Only what the process doesn’t need. Many lines share recipes or interlocks across cells, so cutting a conduit outright can stop production. Log the conduit first, write down the flows it carries over a window that covers batch changes and maintenance, and allow those flows by name.

Is an engineering workstation reaching PLCs always wrong?

No. Programming and diagnostics need it. The question is where the workstation sits: in the cell’s supervisory zone, it is an adjacent hop; at Level 3 reaching straight to Level 1, it skips a boundary and needs a documented conduit with an owner.