OT Security
IT/OT network segmentation
Segmentation between IT and OT is widely recommended and rarely finished. The obstacles are usually organizational, not technical.
The case for separating IT and OT networks is well established: it limits how far a compromise of the office environment can reach into the process environment. The difficulty is that most industrial networks grew organically, and the connections between the two sides were added one business requirement at a time.
Start with what actually crosses
Segmentation designs fail when they are drawn from an idealised diagram. Before defining zones, establish what traffic genuinely flows between IT and OT today — historians pulling process data, maintenance laptops, vendor remote access, patch distribution, licence servers, time synchronisation, and the undocumented link somebody added to make a report work.
Passive traffic monitoring is the safe way to build this picture. It observes without probing, which matters in environments where an active scan can disrupt a device.
Zones, conduits and a demilitarised zone
The common pattern places an industrial DMZ between the two environments. Systems that need data from both sides — historians, jump hosts, patch repositories — live there, and neither IT nor OT connects directly to the other. Traffic terminates in the DMZ and is re-originated.
Within OT, further zoning by process area or criticality limits lateral movement. A compromise in one cell should not reach another simply because they share a flat network.
Remote access is the hard part
Vendor remote access is frequently the widest path into an OT environment and the least governed. Access that is always on, shared between engineers, and authenticated with a static credential is a standing risk. Brokered access through a jump host, with individual identities, multi-factor authentication, time-bounded sessions and recording, is achievable without preventing suppliers from doing their work.
Getting it implemented
Segmentation is disruptive if applied at once and safe if applied in stages. Enforcement can begin in monitoring mode, so rules are validated against real traffic before anything is blocked. Changes land in planned maintenance windows. Each step should leave the environment working, because a segmentation project that halts production will not be given a second window.
Keeping it
Segmentation decays. New integrations get exceptions, and exceptions accumulate until the boundary is nominal. Periodic review of firewall rules against the documented conduits, with an owner and an expiry for every exception, is what keeps the design real.
Seeing something similar in your environment?
Talk to the team