OT & ICS Testing
Safety-first testing of SCADA and PLC environments
In an industrial environment the worst outcome isn't a data breach, it's a physical one. A standard IT scanner pointed at a PLC can halt it, so we don't do that. Production networks get passive observation only; active testing happens against identical non-production equipment in an isolated lab. Every session runs in an agreed maintenance window with a plant engineer present who can stop it with one word.
What we cover.
- SCADA, DCS, and PLC systems
- HMIs, engineering workstations, and historians
- IT/OT boundary and network segmentation, assessed against the Purdue model
- Passive observation on production; active testing only in an isolated lab
- Standard IT scanners are explicitly prohibited on production networks
How the engagement runs.
Introduction
An operational technology penetration test assesses industrial control systems — SCADA, distributed control systems, and programmable logic controllers. These systems control physical processes: manufacturing lines, power generation, chemical processing.
The prime directive: safety and availability first
In IT, confidentiality usually leads. In OT the priority order is inverted, and that changes how everything is run.
1. Safety
The physical safety of personnel, the environment, and the public. Nothing outranks this.
2. Availability
Continuous, real-time operation of the industrial process.
3. Integrity
Ensuring data and commands are accurate.
4. Confidentiality
A distant fourth — which is the opposite of an IT engagement.
This methodology is built on a non-negotiable principle: the test must not, under any circumstances, cause a loss of safety, availability, or control. All active or potentially disruptive testing is reserved for an isolated, non-production lab.
Test phases
Planning and scoping
Far more detailed and rigid than any other kind of test.
- Primary objective — identify vulnerabilities that would let an attacker cross the IT/OT boundary and affect a physical process, without causing an outage in the process of finding out.
- Secondary objectives — validate network segmentation against the Purdue model, identify vulnerable assets and misconfigurations, and assess physical impact in a controlled lab.
- In scope — specified network segments such as the control network and DMZ, and specified systems: HMIs, engineering workstations, historians.
- Out of scope, strictly enforced.
- The live production process control network and safety instrumented systems are off-limits to any active scanning or testing
- Any device the vendor has warned against scanning
- Active exploitation of any kind on any production system
- Rules of engagement — these are mandatory, not preferences.
- Testing window — scheduled during a planned maintenance shutdown. Testing against a live running process is forbidden
- SME escort — a qualified plant engineer or operator with stop-button authority physically present with the tester at all times
- Test lab — you provide a non-production rig with identical or equivalent controllers and HMIs for all active testing
- Stop command — a single verbal 'stop' from the escort halts all activity immediately
- Tooling — every tool approved in advance. Standard IT scanners are forbidden on the production network; OT-safe tooling is required
Reconnaissance — passive and cautious
Building an asset inventory without disturbing operations.
- Passive OSINT — vendor manuals, HMI screenshots, and network diagrams that staff or integrators have published without realising, plus ICS advisories for your specific vendors.
- Passive network reconnaissance — the primary method. A SPAN or tap port gives us a mirrored copy of traffic, read with OT protocol dissectors.
- Asset identification — discovering active controllers, HMIs, and remote units purely by observing their traffic
- Protocol discovery — establishing which industrial protocols are actually in use
- Communication mapping — determining which devices are masters and which are slaves
- Cautious active reconnaissance — only if the rules of engagement permit, only inside the maintenance window, and only with the escort present. A default full port scan can and does crash fragile OT devices, so it is never used. We prefer vendor discovery utilities that speak the safe proprietary protocols, or narrowly targeted OT-safe scripts against a single known port.
Vulnerability analysis
- Vulnerability mapping — correlating the discovered inventory against default credentials, insecure-by-design protocols, and published ICS advisories.
- Purdue model violations — the key focus. Can an HMI reach the internet directly? Can a workstation on the corporate network send a command straight to a controller? That is a critical segmentation failure and usually the finding that matters most.
- Test rig attack planning — scenarios developed for the offline lab only.
- From the engineering workstation, can its own software push a modified program to the test controller?
- From the control network, can a simple protocol script issue a stop command?
- Can traffic between the test HMI and controller be intercepted to produce a false reading?
Exploitation — simulated, lab only
This phase is never performed on the production network. Every activity here happens in the isolated non-production lab.
- Initial access — for instance exploiting a vulnerability on the IT/OT jump box.
- Protocol abuse — interacting with the test controller using OT-specific tooling.
- Read commands — harmless: reading a coil or register
- Write commands — the actual exploit: writing to a register or coil to change a setting or stop the test controller
- Man-in-the-middle — intercepting traffic between test HMI and test controller to inject false data, so the HMI displays a normal reading while a dangerous value is sent to the controller, or the reverse.
- HMI hijacking — using default remote-access credentials to take control of the test HMI.
Reporting
Impact is framed around physical consequence, not data exfiltration. We work with your SME to document what the lab-proven exploit would mean in the real plant.
- Example — finding: the test controller was stopped with a single unauthenticated protocol packet. Impact: immediate shutdown of the assembly line, quantified in lost output per hour.
- Example — finding: a setpoint value was changed in controller memory. Impact: a process could overheat, creating a safety and environmental hazard.
- Executive summary written in operational and financial terms — physical risk, safety, business continuity.
- Technical report with the attack narrative: how the IT/OT boundary was crossed, and what was then demonstrated in the controlled environment.
Remediation
This is not IT. You cannot simply patch a controller — patches are vendor-dependent, often require a full plant shutdown, and sometimes do not exist. The focus is compensating controls.
- Network segmentation — the single most important remediation. Enforce the Purdue model aggressively with firewalls, blocking all IT-to-OT traffic except what is explicitly proxied and required.
- Passive monitoring — deploy OT-aware monitoring that detects anomalous commands, such as a stop command issued by a device that has never sent one before.
- Harden the boundary — secure jump boxes, engineering workstations, and HMIs: multi-factor authentication, default credentials changed, access restricted.
- Vendor patching — a plan to apply vendor-approved patches during scheduled maintenance windows, rather than an aspiration to patch continuously.
What you get at the end.
Who it's for
Manufacturing, energy, utilities, and any operator whose systems cannot be taken offline for testing.
Need a scope for this engagement?
Tell us what's in your environment and we'll come back with a scoped plan.