Building an OT SOC: detecting attacks in control technology
We build your OT security operations centre: passive sensors in the right places, use cases for industrial protocols, playbooks for responding without stopping production. Your team runs it afterwards.
You would not notice if somebody were on the network
Firewalls, segmentation and hardened access reduce the attack surface. None of them is complete. But whoever does not detect that somebody is on the network cannot respond, and in OT environments attackers regularly go unnoticed for months.
An existing IT SOC does not close that gap. It detects malware on a server and a login from the wrong country. It does not detect a switching command arriving over a telecontrol protocol at a time when nobody switches, or a device answering on the process network that was never installed there. Events like that are protocol-conformant. They only stand out against the background of normal operation, and an IT SOC does not know it.
Three points at which an OT SOC fails
The hard part is not the platform but these three, and all of them fall in the build phase.
Visibility without intervening
Monitoring must not touch the process. Every discussion about OT sensors begins with the worry that the instrument itself becomes the source of a fault. Without an answer that can be evidenced, no project gets past those responsible for the plant.
Use cases that do not come ready-made
For IT environments, vendors supply rule sets. For a substation, a production cell or an interlocking environment they do not. Whoever cannot develop their own use cases runs a SIEM that collects logs and detects nothing.
Response without standstill
An IT playbook isolates the affected system. In OT, isolation may mean a production stop or an interruption of supply. The question is not how to shut down but how to contain without shutting down.
Creating visibility passively
The sensor hangs on a mirror port and only reads along. No return channel, no active queries, no intervention in the process. That is the answer to the first objection, and it has to be technically evidenced, not asserted.
Out of the capture comes first a baseline: which devices speak to which, over which protocols, at what rhythm. Only on that can an anomaly be defined at all. Plus the logs of the transitions between IT and OT, because that is where the routes used in practice run.
Use cases from three sources
First from the tactics and techniques model for industrial environments: access through remote maintenance, manipulation of control commands, suppression of reporting functions. We map those techniques onto concrete rules and measure which part of them would be detectable in your environment at all.
Second from publicly analysed malware for industrial controllers, whose behaviour is documented and can be translated into detection scenarios.
Third from our own testing work. We know which attack routes work in OT environments and what traces they leave, because we have taken them ourselves. No vendor has that source.
Playbooks that know the operation
Detection without response is an expensive log file. So the playbooks answer the questions IT playbooks leave out: can the affected system be contained without stopping production. Who decides that, and in what time frame. Who has to be informed when, internally and towards the regulator.
That gets practised beforehand. A facilitated incident exercise with distributed roles reliably shows where the process sticks, and we run such exercises in existing security operations centres too.
What you have at the end
A capability that stays with you.
Visibility
An asset and communication picture of your OT environment, gathered through passive sensors. You know which devices speak to which, over which protocols, and at what rhythm.
Detection
Tuned detection rules and use cases, cut for your environment and your threat picture, versioned and measured against their coverage.
The ability to act
Playbooks for the most common scenarios, a team that has practised, and escalation and reporting paths that are settled. We build, your team runs.
When building a SOC is the right step
Three triggers usually lead here. The first is the duty to detect: NIS2 and the German IT Security Act require operators of critical infrastructure to have systems for detecting attacks, and the duty to evidence that expressly includes the automation.
The second is an existing IT SOC that is to be extended with OT capability. The shift is in place, the processes are in place, but IEC 60870-5-104, IEC 61850 with MMS and GOOSE, or Modbus run straight past the existing rules. Here it is about sensors and use cases, not about building a second organisation.
The third is the question of whether anybody is on the network at all. Whoever cannot answer it sensibly starts with an assessment: it supplies the plant and communication overview a SOC build rests on.
Operation stays with you
We have built several security operations centres in the transport and logistics sector, running since 2019, with use case development as a team of its own, the onboarding of numerous clients, and IT and OT data sources in the same analysis. We work on both of the common platforms, because the choice belongs to the client. Two examples are further down this page.
We test rules on our own hardware first. The lab holds a model city with real telecontrol and substation technology, a Siemens production cell and a train model. What does not fire there does not go into operation.
Plus the research side: in a federally funded joint project we developed intrusion detection for vehicle buses and diagnostic protocols, a security event centre for use on board, and extended the common tactics and techniques model by domains it did not cover. The results are published with ACM and IEEE.
How a build actually begins
It begins with the question of what is visible at all.
First conversation
We establish the scope, the existing data sources and the regulatory constraints. If no assessment exists yet we say so plainly: without an asset inventory and a topology, the basis for placing sensors is missing.
Visibility check
A passive capture at a defined transition point shows what would be detectable today and what would not. The result is a list of gaps, not a product recommendation.
Sensors and data sources
Selection and placement, connection of the firewall logs at the IT/OT transitions and of the telemetry from engineering and control systems.
Use cases and playbooks
Development, testing against the baseline, tuning. Alongside them the response processes and an exercise in which they get run through once.
Handover
Your team runs it; we accompany the first weeks and sharpen where false positives appear.
What gets asked before a SOC build
No, when they hang passively on a mirror port with no return channel. That can be technically evidenced and is the first point we settle with those responsible for the plant.
It is a good basis but does not cover the OT events. The usual route is extending it with OT data sources and OT use cases, not building a second SOC beside it.
No. We work on the common platforms. That decision belongs to you, and it is not the hard part.
Your team. Our aim is expressly not to take over operation but to put you in a position to monitor your own infrastructure.
As a rule, yes. It supplies the asset inventory and the network topology, without which placing sensors is guesswork.
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.