OT penetration testing and assessments
We test your automation the way an attacker would: passively during operation, actively only in an agreed window. At the end there is a map of the real communication paths and a list of findings separated by urgency.
What is documented in a grown OT network, and what runs
An automation environment grows over decades. It outlives several integrators, several generations of control system and a great deal of rebuilding during operation. What comes of that is a plant whose network plan describes the intended state and whose communication describes the grown one.
Between the two sit the remote maintenance path left open after a project, the historian with two network cards, the access granted to a supplier three years ago. That is a consequence of systems that must not be switched off: whoever removes a connection has to prove the plant does not need it.
An assessment supplies exactly that proof. It shows which paths are actually open today, which of them somebody uses, and which can be closed without touching the process.
Three questions, three formats
They answer different things, and the order is rarely arbitrary.
Assessment: where do we stand?
Breadth against a target level. Architecture, segmentation, access concepts and detection capability get assessed and held against the requirements of IEC 62443. The result is a prioritised order of work, not an exploit.
Penetration test: is it exploitable?
Depth on a defined scope. What the assessment named as a risk is actually attempted here, with evidence and reproduction steps. That answers whether a finding is real or theoretical.
Red team: would anyone notice?
Goal-driven over weeks. The point is not the finding but whether detection and response work. Worthwhile only once monitoring exists that could notice something.
Testing without touching the plant
A vulnerability scan that passes unnoticed in an office network can cause a fault in a control environment or trip safety mechanisms. Availability and safety come before confidentiality, and the approach follows from that.
Passive methods first: architecture analysis, configuration review and evaluation of captured communication. That yields most of the answer during live operation. Active tests run only in agreed windows, on spare or lab rigs, with abort criteria fixed beforehand and in agreement with those responsible for the plant.
Where a finding could only be obtained by intervening, we reproduce it on our own hardware rather than forcing it on your plant.
What ends up in your hands
A zone and conduit model to IEC 62443-3-2 that reflects the real communication and not the planned one. A risk register in which every finding is rated by likelihood and impact. A gap analysis against the level required for your plants.
Out of that comes an order of work: what has to be fixed immediately, what belongs in the next maintenance window, and what is documented and accepted as residual risk. Plus a management summary that works as a basis for decisions on budget and priority.
When an assessment is the right step
Most often it starts with a requirement from outside: NIS2, IEC 62443, or a customer who wants to see evidence. An assessment supplies that evidence and, along the way, the basis without which any further measure is guesswork.
The second trigger is an investment coming up. Before rebuilding the network architecture, before introducing a control system, or before procuring monitoring, it is worth asking which communication paths actually exist today. Otherwise an intended state gets secured that does not exist in that form.
The third is a planned SOC build. The plant and communication overview from the assessment is exactly what sensors and use cases build on later.
From plants, from our own lab, from research
We have carried out penetration tests at power plant and substation sites, security assessments in network control rooms, and tested an interlocking landscape over six months without intervening in live traffic. The sectors we work in regularly are energy, rail, manufacturing and public administration.
Preparation and reproduction happen in our own lab. It holds a model city with real telecontrol and substation technology, a Siemens production cell with controllers of the S7-1500 and S7-300 series, a train model and a vehicle rig. Testing procedures that do not run cleanly there do not go into a client plant.
Plus the research side: three and a half years in a federally funded project on vehicle security, together with partners from rail, the automotive industry and research, with an extension of our own to the tactics and techniques model for domains it did not cover until then.
How an OT assessment runs
A week for a focused section; distributed environments with many sites take correspondingly longer. The work is passive during operation; active steps only in an agreed window.
Scope and releases
Which parts of the plant, which network areas, which time windows. Plus the question of who inside is reachable if something stands out, and which abort criteria apply.
Passive capture
Capture at the handover points, evaluation of the protocols that actually run, and the existing documentation laid alongside. No active scan in the production network.
Assessment against IEC 62443
Architecture, segmentation, access concepts and detection capability held against the target level. Where a finding could only be obtained by intervening, we reproduce it on our own hardware.
Zone model and order of work
A zone and conduit model to 62443-3-2 that reflects the real communication, and a list of measures separating immediate, next maintenance window, and residual risk.
Common questions about OT assessments
Testing an automation environment for reachable paths and weaknesses, with regard for the process. Most of it runs passively: capture at the handover points and evaluation of the protocols that actually run.
Active testing takes place on spare or lab rigs, or in an agreed window, with abort criteria fixed in writing beforehand.
In IT you scan, patch and, if need be, restart. In automation each of those three is an intervention in the process. A port scan can put a controller out of step that has run for twelve years.
So the emphasis is on observation and on the question of which communication paths are really open, rather than on a list of version numbers.
IEC 60870-5-101 and 104, IEC 61850 with MMS, GOOSE and sampled values, Modbus, DNP3 and OPC UA in control technology. In the vehicle and rail environment, CAN, UDS to ISO 14229, MVB to IEC 61375 and CANopen.
The risk cannot be ruled out, but it can be bounded. In the scoping we fix which test scenario suits your appetite for risk. We validate our tools beforehand on comparable systems, and for production environments we agree abort criteria. Where no test environment exists, we usually begin with passive analysis and a configuration review.
That depends on the scope. A focused analysis of individual systems is finished within a week. Plants with several network segments take correspondingly longer. After the first conversation we can evidence the effort.
Yes. Send us the hardware and we examine it in the lab: firmware analysis, protocol implementation, debug interfaces. That is worth it before procuring new components and for security approvals.
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.