OT/ICS security in GCC power and utilities is mainly a network architecture and third-party access problem, not a malware problem: SCADA, DCS and safety systems get compromised because a route exists from a corporate network, a vendor VPN, or an engineering laptop into equipment that was never built to defend itself. Close those routes and most of the realistic attack paths close with them.
- Most OT incidents in the region start on the IT side and move sideways through a shared engineering laptop, a historian server, or vendor remote access, not through a direct hit on a PLC or RTU.
- Active vulnerability scanning on a live control network can crash fragile devices, so OT assessments lean on passive monitoring and configuration review instead.
- Segmentation diagrams look clean in an audit and get punched full of holes the rest of the year, because maintenance windows and vendor support keep reopening the paths.
Why OT security does not behave like IT security
An IT team patches on a monthly cycle and reboots without asking permission. An OT team cannot. A turbine control system or a substation RTU often runs an operating system version the vendor certified years ago, and touching it outside a planned outage window risks the one thing OT teams are measured on: uptime and safety, not confidentiality. That difference in priority, availability and safety first, confidentiality a distant third, is why security controls that are routine in a data centre (endpoint agents, aggressive patching, network scanning) are either impossible or actively dangerous on a control network.
Proprietary and semi-proprietary protocols compound this. Modbus, DNP3, IEC 61850 and OPC were designed for reliable communication between trusted devices on an isolated network, not for authentication or encryption. Bolting security onto them after the fact, rather than replacing decades of installed field equipment, is the practical reality every GCC utility and power operator is working within.
What actually gets attacked, and what usually gets misremembered
The 2012 Shamoon attack on Saudi Aramco gets cited constantly as an OT security case study, and it is worth being precise about what it actually was. Shamoon destroyed data on thousands of computers on Aramco's corporate IT network. It did not touch the control systems running the oil and gas process itself; production continued because the operational network was separated from the business network that got hit. The real lesson from that incident is the opposite of how it is usually told: segmentation held, and a serious IT breach still caused significant disruption to the business side, from shipping to internal communications, because so much of it depended on the compromised network.
The attacks that did target control systems directly are less well known regionally but more instructive. Triton, also called Trisis, hit the safety instrumented system of a Saudi petrochemical plant in 2017. It specifically targeted the Schneider Electric Triconex controllers that exist to shut a process down safely when something goes wrong, meaning the attacker's objective was plausibly to disable the safety layer before triggering a physical incident, not just to steal data or cause an outage. Industroyer and its 2022 successor, aimed at the Ukrainian power grid, were purpose built to speak the same protocols as grid protection relays and issue commands the equipment would treat as legitimate. Neither of these required a zero-day in Windows. Both required an adversary who had already reached the OT network and understood the protocol well enough to be believed by the equipment.
The entry points that actually matter
In assessments across GCC critical infrastructure, the recurring weak points are not exotic:
- Vendor and system integrator remote access left permanently open, or protected by a shared credential rather than per-engineer access with logging.
- Engineering and maintenance laptops that get used on the corporate network, patched inconsistently, and then plugged into the control network during a site visit.
- Historian and data diode setups where the "one-way" flow to the business network was, at some point, made bidirectional to support a dashboard or predictive maintenance feed, and nobody rolled that back.
- USB media used for firmware updates and configuration backups, still common on equipment with no other update mechanism.
Segmentation: the diagram versus the daily reality
The Purdue model, splitting the enterprise network, the DMZ, and the control network into layered zones with defined conduits between them, is the reference architecture every OT security consultant will draw for you. It is also aspirational at most GCC power and utilities sites, because it was retrofitted onto plants built over twenty or thirty years, added to piecemeal as SCADA systems were digitised and connected to business intelligence tools.
What assessors actually check is not whether the diagram exists but whether the conduits between zones are still doing what the diagram says: is that firewall rule between the DMZ and Level 2 actually restricted to the specific ports and hosts it claims, or was it opened wider six months ago to fix a support ticket and never tightened back up. A network segmentation review that only reads firewall documentation misses this. One that pulls the live ruleset and traces actual traffic flows against the intended zones and conduits finds where the operational reality diverged from the design. For sites managing that boundary with more granular, identity aware access rather than flat network trust, the same segmentation and access review approach used in a broader zero trust network access rollout applies directly to OT remote access.
Assessing OT without breaking it
Standard penetration testing assumptions do not carry over to a live control network. An active scan that would be routine against a server farm can send a fragile embedded controller into a fault state, and on a power or water utility that fault state is not an inconvenience, it is a service disruption with public consequences. A competent OT engagement adjusts the method rather than skipping the assessment: passive network monitoring to build an asset inventory and baseline of normal traffic, configuration and firmware review against vendor advisories, active testing reserved for a lab replica or genuinely redundant spare equipment, and any intrusive testing on production scheduled inside a planned maintenance window with plant engineers present. This is a different discipline from a standard external or internal VAPT engagement, and scoping it correctly, agreeing what is off limits before testing starts, matters more in OT than almost anywhere else in security testing.
Getting OT visibility into the SOC without an OT-specific team
Most GCC utilities do not have, and cannot economically staff, a dedicated 24x7 OT security operations function. The practical path is bringing OT telemetry into the same SIEM the IT SOC already watches: passive sensors tap the control network traffic (typically via a SPAN port or physical tap so nothing touches the live line), decode the industrial protocols, and forward normalised events and anomaly alerts into the SIEM alongside IT logs. A platform like FortiSIEM is built to correlate that OT telemetry against IT and network events in one place, which matters because the incidents worth catching, a compromised vendor VPN session followed by unusual traffic to a PLC, span both domains and are invisible if IT and OT logs sit in separate tools nobody cross-references.
Detection logic has to change too. Signature based IT detection assumes constantly shifting traffic and known malware hashes. OT networks are the opposite: traffic patterns are repetitive and predictable, so the highest value detections are behavioural, a new device appearing on the network, a write command sent from a host that has only ever read, a protocol function code that has never been used before on that segment. That baseline only exists if someone did the passive discovery work first.
Where regulation is heading
UAE and GCC critical infrastructure operators, power and utilities included, sit under sector-specific regulatory oversight because sustained disruption to grid or water service is a national security and critical infrastructure protection concern for the state, not just an operational one for the operator, and assessors increasingly expect evidence structured around the ISA/IEC 62443 zones and conduits model rather than a generic IT framework. Expect assessors to ask for an asset inventory that actually matches the network, evidence that remote access is per-user and logged rather than shared, and a segmentation review with real traffic evidence, not just a network diagram. Our OT/ICS security FAQ covers the specific questions that come up most often in these assessments.
A starting point that does not require a full OT security programme
If a full IEC 62443 programme is not realistic this year, three things move the needle regardless of budget: get an accurate asset inventory of everything on the control network (most sites cannot produce one on request), review every vendor and third-party remote access path and kill the ones that are not per-user and logged, and stand up passive monitoring even without an OT SOC, because a baseline you can look back on after an incident is worth more than no visibility at all. Everything else, including a formal VAPT engagement scoped for the live environment, gets easier once those three exist.
