OT/ICS security is the network design, monitoring and process controls that keep industrial control systems (SCADA, PLCs, DCS, safety systems) running safely and continuously. The priority order reverses IT security: availability and physical safety come first, confidentiality last, because a stopped process can mean a spill, a blackout or an injury, not just a data leak.
- OT protects availability and safety first; IT protects confidentiality first, and a tool built for one often damages the other.
- The best-documented public OT incidents reached the process through engineering workstations or safety systems, not by hacking a PLC directly.
- Asset inventory and network segmentation reduce more risk than any single product purchase.
- Active vulnerability scanning can crash legacy PLCs, so OT monitoring has to start passive.
- UAE and GCC assessors ask for evidence, not brand names: zone diagrams, change logs, a tested OT runbook.
Why OT security is not IT security with different hardware
IT security defaults to confidentiality, integrity, availability, in that order. OT flips it: availability first, because a halted line or tripped safety system has physical consequences; integrity second, because a manipulated setpoint can be as dangerous as an outage; confidentiality last, since most process data has little resale value.
That flip changes the controls. You do not reboot a PLC to patch it mid-shift; you wait for a planned outage window that might be months away. You do not push an endpoint agent onto a legacy embedded HMI a vendor still requires for warranty support. You do not run an authenticated scan against a serial-to-Ethernet gateway that was never built for malformed packets, because it will fall over. Modbus and DNP3 were designed decades ago for reliability on a closed network, not authentication on a converged one. Bolting IT-style controls onto that environment without adjusting for it is how a security team takes a plant offline itself.
What has actually happened, and what it teaches
A handful of public, well-documented incidents shape how serious OT teams think about this.
Stuxnet (2010) compromised engineering workstations running Siemens Step7 software, then reprogrammed centrifuge controllers while feeding operators normal readings, rather than attacking a PLC directly. Lesson: the engineering workstation, not the PLC, is usually the weakest link, since it runs a general-purpose OS and gets used for more than engineering.
The Ukraine grid attacks (2015 and 2016) started with phishing into the IT network, then pivoted into SCADA to open breakers and cut power to hundreds of thousands of customers; the 2016 tool spoke the grid's own protocols natively. Lesson: IT/OT segmentation is only as good as the accounts and jump hosts allowed to cross it.
Triton/Trisis (2017, a Middle East petrochemical facility) targeted Schneider Electric Triconex safety instrumented systems, the layer that exists purely to prevent catastrophic failure. Lesson: safety systems need their own segmentation, separate from the control systems they backstop.
None started with a zero-day against control hardware. All three started in the IT layer, or the tools bridging IT and OT, then moved sideways.
Why UAE and GCC operators carry outsized exposure
The region concentrates the sectors OT security exists to protect: oil and gas, power and water, ports and logistics, and increasingly desalination and renewables. Three factors raise the exposure. Brownfield reality: control systems on a fifteen to twenty year lifecycle were specified before IT/OT convergence was a design consideration, so segmentation gets retrofitted onto plants never drawn with a DMZ in mind. Vendor remote access: OEMs and integrators often hold standing access for maintenance, rarely reviewed with the rigor of an employee account. Convergence itself: historian data now flows to cloud dashboards because operations wants visibility, and each flow is a path back into the control network if it is not built one-way.
The Gulf energy sector has also been a repeat target for destructive attacks going back to the Shamoon wiper campaigns, part of why regional operators take OT segmentation seriously even where OT-specific tooling budget lags behind IT.
An architecture, not a product
No single purchase secures an OT environment. The order that actually reduces risk:
Asset inventory first. You cannot segment, monitor or patch a device you do not know exists, and most OT networks hold more devices than the as-built drawings show. A passive scan that fingerprints traffic without touching devices is the safe way to build this list; an active scan against an undocumented serial gateway shows you the hard way what a fragile stack looks like.
Segmentation by zone and conduit, following the Purdue model's logic even without implementing it literally: enterprise network, site operations network, control network, each separated, with a demilitarised zone between the site and enterprise sides, not a single firewall rule. Where the consequence of a breach is severe enough, a unidirectional gateway that physically permits data out but nothing in is worth the friction it adds.
Monitoring that respects the fragility of the assets. Passive, protocol-aware monitoring reading Modbus, DNP3 and OPC traffic off a span port shows what is talking to what, and flags a new workstation issuing write commands, without touching the PLC. Active scanning stays reserved for supervised maintenance windows.
A patching alternative, because most OT assets cannot follow an IT patch cadence. Compensating controls, virtual patching through an inline IPS signature, and strict change control around the eventual outage window matter more here than a patch SLA borrowed from IT.
Feeding OT telemetry into a SIEM that was not built for OT
Few UAE and GCC operators run a dedicated OT platform end to end. The more common, defensible pattern is a passive OT sensor at the network boundary feeding normalised events into the same SIEM platform already ingesting IT logs, so one team gets one view instead of two consoles nobody reconciles.
On a platform like FortiSIEM, that means syslog or CEF feeds from historians and the OT sensor, correlated against IT identity events so a compromised vendor VPN account touching the OT DMZ trips an alert before it reaches the control network. The choice that matters: keep the OT collector one-way into the SIEM.
What UAE assessors actually check
The UAE Information Assurance Regulation and sector critical infrastructure guidance are relevant here, but the useful version is what an assessor asks for in the room, not a claim about what a regulation mandates. Expect to be asked for an asset inventory with firmware versions, a network diagram matching the current configuration rather than the commissioning drawing, evidence of change control on the control network, a tested incident response plan specific to OT, and proof that vendor remote access is time-bound and logged rather than standing.
Boards sometimes treat this as a paperwork exercise before an audit. Assessors who have seen a real OT incident ask when the diagram was last validated against a live scan, which is usually where the gap shows.
Vulnerability management, done differently for OT
A vulnerability management programme built for IT assumes continuous scanning and a set patch cycle. Neither holds in OT. It needs a vendor-validated patch list, a compensating control catalogue for what stays unpatched until the next outage window, and a scanning cadence tied to maintenance windows rather than a calendar. The common questions operators raise about OT/ICS security cluster around exactly this: reconciling a fixed patch cycle with a network that cannot tolerate downtime outside a planned window.
Five questions before the next budget cycle
An operator should be able to answer these without a consultant in the room. Is the asset inventory built from network traffic, not commissioning drawings. Is there an actual DMZ between site and enterprise networks, with documented rules, not one firewall interface doing double duty. Is OT monitoring passive by default, with active scanning reserved for supervised maintenance windows. Does vendor remote access expire automatically, or does someone have to remember to revoke it. Has the OT incident response plan been tested with the operations team in the room, not just security.
If more than one answer is no, that is the priority list, in that order, whatever the next vendor pitch leads with.
