JNCIA-Design study materials
JNCIA-Design study resources

OT/IT Segmentation for a Plant With Unpatchable HMIs

JNCIA-Design · Put your knowledge to work in context.

All case studies

OT/IT Segmentation for a Plant With Unpatchable HMIs

Calderon Foods operates one plant with 300 OT devices (PLCs, HMIs, and 12 Windows XP HMIs that cannot be patched until the line is rebuilt in 2027), 500 IT users, a DMZ with three public web servers, 200 guest devices, and vendor remote access for nine integrators. Everything is one flat 10.0.0.0/16 behind an internet-edge firewall; the only internal control is a router ACL between office and plant. Last quarter a laptop on the office LAN infected two HMIs and stopped line 3 for 11 hours because broadcasts and SMB were unrestricted. Safety instrumented systems share a switch with the line HMIs today. Six cafeteria kiosks take card payments, so PCI DSS scoping is now on the audit list. The plant manager will approve downtime windows of two hours, twice a year, and nothing else - so anything requiring re-cabling the line is off the table.

1. Propose the zone architecture and name the enforcement point for each boundary, given the two-hour maintenance windows.

Read the worked answer

Zones: IT users, IT servers, internet DMZ, guest, OT supervisory (HMIs and engineering workstations), OT control (PLCs and drives), safety instrumented systems, and the payment kiosks. The critical move is separating safety from the HMIs that just got infected - today they share a switch, which means an HMI compromise is one broadcast domain away from the SIS. Put SIS on its own VLAN (ideally its own switch) with no routed path to IT and no path to the HMIs; the two-hour window is enough for a VLAN and ACL change, not a re-cable, so use the existing hardware. Enforce IT-to-OT at an internal firewall, or at minimum on a pair of Layer 3 switches with VRF separation and stateless ACLs if the firewall budget is not approved - but the firewall is the right answer because OT traffic needs logging and stateful inspection, and the audit will ask for it. Inside OT, use ACLs on the industrial switches between supervisory and control. Policy is default deny with named permits: SMB only from two engineering hosts to the file server, Modbus/TCP 502 only between specific HMI and PLC pairs, no OT device reaching the internet at all. Contain broadcasts per zone with /24s and storm control, since broadcast flooding was part of the 11-hour outage.

2. Design remote access for nine integrators so that vendor connectivity stops being another flat path into the plant.

Read the worked answer

Today, whatever VPN the vendors use lands them somewhere in 10.0.0.0/16, which is functionally the same as handing them a desk in the plant. Replace it with a brokered path: terminate vendor VPNs on a jump host in an OT-DMZ zone that has no general route into IT, require MFA (certificate plus TOTP), and give each integrator a named, time-boxed account sponsored by a plant engineer with an end date that matches the work order. From the jump host, permit only the specific destination IPs and ports for that vendor's equipment - the packaging integrator reaches the three PLCs on line 2, not the plant. Session recording and command logging are not optional when the vendor is running a legacy HMI; that log is the only forensic trail you will have if something goes wrong at 02:00. Disable split tunnelling and do not allow the vendor laptop to become a router into the OT segment. If the integrators need 24/7 support access, use an OT-aware remote access broker with per-request approval rather than a permanent VPN group, because the permanent group is exactly what will be credential-stuffed six months from now. Confirm the vendor's patching posture and that their tooling can speak TLS 1.2, since the XP HMIs cannot.

3. Advise on TLS inspection and IPS placement, including what must be exempted, and state how to reduce PCI scope for the six kiosks.

Read the worked answer

Inspect selectively. Inline TLS inspection belongs on the IT-user internet egress and on inbound traffic to the DMZ web servers, where the risk is a user clicking a link or a web server being attacked, and where you control the certificate chain. Do not decrypt OT traffic: the XP HMIs cannot negotiate modern TLS, several OT cloud brokers pin certificates, and breaking inspection there buys signatures you cannot safely act on anyway. For OT, run the IPS passively, in tap mode with ICS-aware signatures - generic IT signatures on Modbus or CIP traffic will generate noise at best and block a production line at worst. On the payment kiosks, do not decrypt cardholder traffic at all: TLS interception of the card data path pulls the firewall itself into PCI scope and the auditor will say so. Shrink scope instead: put the six kiosks in their own zone with outbound-only access to the acquirer's published IP ranges, no route to the corporate LAN, and, if the terminals support it, point-to-point encryption so the card data is enciphered at the terminal and the network never sees it. That turns a network segmentation project into a scope-reduction argument you can take to the auditor, and it costs nothing in plant downtime, which is the only currency the plant manager cares about.