OT/ICS penetration testing

The difference is in what happens when something goes wrong. On a web server an active scan finds a flaw and at worst a service goes down, which you restart. In OT the same scan or exploitation attempt can crash a live PLC, that is, the programmable controller that runs the production process, and stop the line or endanger the safety of the people next to it. It’s generally true that industrial equipment may not tolerate even a scan, and here that’s a reason for caution, not a platitude.

Industrial systems are also built for years of uninterrupted running, not for unusual traffic. Control units run for years without a restart, have limited memory, and don’t expect anyone to send them an unexpected request. What an IT network shrugs off can, in OT, cause an outage that costs more than the whole test. Operational safety is the first thing, not the second after findings.

It doesn’t mean OT can’t be tested. It means it’s tested differently: more listening and analysis, less active interference with operations, and what does have to intervene is done when agreed and in a window operations can bear. We treat this discipline as part of the profession, not as an excuse. How it differs from an ordinary pentest is also covered by an article on why OT is tested differently from IT.

We start at the boundary between IT and OT. The Purdue model, that is, the layered arrangement of an industrial network from corporate IT down to sensors and actuators, describes where the boundaries between zones should be. We look at whether those boundaries are there in practice, or whether the control units can be reached straight from the office network. The wired IT network below that boundary is checked by the infrastructure test, which shows where the IT network ends and OT begins.

Then we go after the industrial protocols. Modbus, DNP3, and OPC carry commands between the control system and the devices, and many of them were created at a time when an attacker on the network wasn’t expected, so they have neither authentication nor encryption. We watch where they flow, who can see into them, and whether a command can be spoofed or intercepted.

The components themselves and access to them are also in scope: the configuration of PLCs and RTUs, that is, the units that collect data and control processes in the field, of HMI stations and SCADA or DCS systems through which the operator runs the process, and above all remote access into OT. Remote maintenance by a supplier is exactly the path by which someone from outside gets into the industrial network.

The basis of the work is passive. We listen to the traffic on the network and analyze configurations without actively intervening in the systems, so operations don’t know about the test. Passive listening reveals a surprising amount: which protocols run, who talks to whom, where segmentation is missing, and where commands go without authentication.

We take active steps only where they make sense, and only with approval. We plan them into a maintenance window, when the process is shut down or in a mode that can bear the intervention, and we run them in cooperation with your operations team, which keeps a hand on the switch. Where a test or backup environment exists, we move the risky steps there. Industrial operations may not have one, though, and we account for that.

Before every risky step we call and describe what we’re about to do and what could, in theory, happen. We leave the decision to whoever is responsible for operations. We’d rather document a finding with the configuration and a description of the impact than with an attempt that would endanger production. Caution here isn’t a weakness of the test; it’s the condition for it to happen at all.

IEC 62443 is an international series of standards for the security of industrial automation and control systems. It describes how an OT network should be divided into zones and the conduits between them, what security levels they should have, and what’s expected of the operator and of the technology supplier. It’s a reference framework you can measure against.

We map findings to it: we show where the configuration or segmentation doesn’t meet the standard’s requirements and what to change so that it does. We don’t issue an IEC 62443 certificate, though; that’s for a certification body. We provide the technical view and the steps toward compliance. Part of OT operations also falls under regulation, and whether your operation is a regulated service we go through right at the start.

The effort rests on the number of sites, the number of zones under the Purdue model, the number of devices, and the number of different protocols in operation. One factory floor with one PLC is different work from three plants with their own SCADA systems and remote maintenance; in OT the number of zones and devices decides, not the number of IP addresses.

The effort is 5 to 10 person-days, and in calendar time it’s two to three weeks from the start to report delivery. You get the exact proposal after the scope is defined, not as an open hourly rate; the price and scope of an OT and ICS test come from the number of sites, zones, and devices.

First, cooperation from operations. An OT test can’t be done without the people who know the systems and are responsible for them, because they know what each intervention does and when the safe window is. Along with that, we need a network diagram and the division into zones, a list of the main devices and protocols, and a contact for the person responsible for operations, available throughout the test.

Then an agreed maintenance window for the active steps, and rules of engagement: what may be done passively at any time, what only in the window, and what is entirely out because operations can’t bear it. These rules are agreed in advance, not once the test runs into a live device.

A report, not a scanner export. Every finding has a description, the impact on operations, evidence, and specific remediation, plus mapping to IEC 62443, so it’s clear which requirement of the standard it concerns. We order severity by the impact on your operations and safety, not by a generic score, because in OT even a seemingly minor flaw in the wrong place can have a large impact.

For findings where a path leads from IT to OT or straight to a control unit, we describe the whole chain of steps, so it’s clear why it’s a risk. One retest of fixed findings is included in the price, and we plan it, like the test, so the verification doesn’t disturb operations.