What your OT monitoring should catch during an ICS pentest

The visibility gap most OT networks carry into a pentest

An OT/ICS pentest opens on a network built for deterministic control, not observability. Legacy PLCs and RTUs generate no logs. HMIs run unpatched operating system versions that predate modern EDR. Historians sit on isolated subnets with no forwarding rule to any SIEM. Most security teams have near-zero visibility into the live operational network.

That gap is not a reason to delay the pentest. It is the first finding. A test run while your monitoring is blind shows exactly what an attacker could do without triggering a single alert. For each technique the pentest uses, your security team needs to know whether anything fired, and if nothing did, what would need to change.

Why passive monitoring is the only safe approach in the control network

Active scanning in an OT network is not safe. Many PLCs and RTUs respond to unexpected traffic by entering a fault state, and a single ICMP sweep to the wrong address can interrupt a running process. That is what separates an infrastructure pentest from an ICS engagement: the pentest team uses passive techniques in the control network, and your monitoring must do the same.

A passive tap on the OT DMZ switch and a span port on the main OT LAN segment cover most of what the pentest team will do. From those two positions, a passive sensor running Zeek or a purpose-built OT protocol parser can reconstruct every session, parse every Modbus transaction and flag every new host on the segment. Deploy both before day one, or the monitoring question cannot be answered.

Asset inventory is a secondary benefit of passive monitoring, but a real one. Many OT asset registers are out of date. The pentest team will find devices nobody knew were on the network, and your monitoring platform will too. A device absent from the asset register that begins communicating on EtherNet/IP is both a pentest finding and a standing detection gap.

Protocol-level anomalies: what to look for and why they matter

The control network carries a small, predictable set of protocols. Modbus TCP, DNP3, EtherNet/IP, OPC-UA and PROFINET cover most industrial environments, and within each, normal traffic follows strict patterns. A SCADA master polls the same PLC coils at the same interval. A historian queries the same OPC-UA tags. An HMI reads the same registers. Any deviation is the signal your monitoring should act on.

MITRE ATT&CK for ICS documents the techniques a pentest team and a real attacker use. Most produce protocol-level anomalies: an unexpected write to a coil or register, a function code the SCADA master never sends, a new source IP in an EtherNet/IP session. None of those are hard to detect. They require a parser that understands the protocol and a baseline of what normal looks like. Without the baseline, every write looks identical, and the one the pentest team issued to show impact is invisible.

Zone crossings: detecting the move from IT into the OT network

The path from a compromised IT workstation into the OT network runs through the DMZ. The historian is the most common stepping stone: it holds a database connection to the SCADA tier and an MSSQL port open to the IT segment. From there, a jump server or an RDP session gives access to an engineering workstation and from there to the HMI. None of those steps use OT-specific protocols. They run over standard IT protocols your existing monitoring can see.

Watch for a new source IP querying the historian database, an RDP session from the historian subnet, and an engineering workstation opening PLC programming software outside a maintenance window. The sequence is the signal. No single step is conclusive, but a new IP reaching the historian followed by an RDP session to an engineering workstation within the same hour is a chain your SIEM can detect today, without OT-specific tooling.

This is why the boundary between your IT and OT monitoring matters. An assumed-breach engagement starting from a corporate workstation will cross your firewall, appear in the historian's access logs and use RDP. If those three sources are not correlated, the chain is invisible. The pentest is the controlled test that shows whether the correlation rule exists or needs to be written.

Turning pentest observations into detection rules that stay working

Every technique the pentest team used that produced no alert is a gap. The gap is only closed when a detection rule exists, has been tested against a real replay of the technique and has an owner. A finding noting that no alert fired on a coil write from an unexpected source is useful. A production Modbus write detection rule that fires on the next test and is assigned to an engineer is the actual deliverable.

That translation happens in a purple team follow-up. The pentest team replays each technique while the blue team watches the monitoring platform and tunes the rule until it fires reliably. In OT environments this matters more than in IT: the low-change-rate baseline means a well-tuned rule has almost no false positives once deployed. The signal is real. The only question is whether anyone wrote the rule.

A full OT/ICS pentest ends with a list of detection gaps alongside the vulnerability findings. For each gap, the question to answer before the report closes is: what is the specific query, in your SIEM or OT IDS, that would have caught this? NIST SP 800-115 describes this as a core output of a technical assessment. The NIST Cybersecurity Framework treats detection as a function that must improve continuously, not one set once. Both documents apply to OT environments, not only to IT.

OT detection in the UAE: what Abu Dhabi and Dubai operators face

The UAE operates critical infrastructure across energy, water, transport and industrial sectors in Abu Dhabi and Dubai. Many of those assets fall under federal cybersecurity obligations set by the Telecommunications and Digital Government Regulatory Authority through the UAE Information Assurance Regulation. That regulation requires entities operating critical information infrastructure to maintain monitoring and incident detection capabilities. For OT operators, the requirement extends into the control network, not only the enterprise tier.

In Abu Dhabi, ADHICS applies to healthcare facilities operating industrial medical systems. In Dubai, DESC obligations extend to government-connected suppliers running OT environments. Operators in both emirates under CBUAE oversight, including financial institutions running automated payment and settlement infrastructure, face detection requirements that now explicitly reference OT-adjacent systems. None of those regimes use the language of the Purdue Model, but the intent is the same: show that you can see what is happening in your operational network and respond to it.

Many UAE facilities were built before any cybersecurity monitoring requirement existed, and retrofitting passive sensors into a live control network requires change-control processes that can take months. Deploying passive monitoring before the pentest is scheduled is not optional if the engagement is to produce a meaningful detection assessment. An OT/ICS pentest run against an unmonitored network produces a vulnerability list but not the detection maturity evidence a UAE regulator is likely to ask for in the next audit cycle.

Frequently asked questions