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.
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 only reads along. No return channel, no active queries, no intervention in the process. Where the signal is tapped still has to be examined. A mirror port runs through the switch CPU and can itself become a source of disturbance under load. A passive TAP couples the signal out physically and does not have that property. So for every transition we fix beforehand what runs over a TAP and what over a mirror port, and we record the load on the switch while doing it.
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.
One use case, end to end
A lot can be written about use cases. What convinces is one written out in full, with trigger, source, threshold, the false positives it produces and the response that follows. This one catches a command that is protocol-conformant and still must not happen.
| Field | Content |
|---|---|
| Trigger | A write command to a controller outside the approved switching times |
| Data source | Passive capture at the crossing into the process level, evaluated by the OT IDS |
| Detection logic | A function code with write effect, a target device in the process zone, a time outside the stored schedule, a source not on the list of approved engineering stations |
| Threshold | A single event. With this pattern a cluster is not a better signal, only a later one |
| Typical false positives | Maintenance without a registered window, a replacement device on an old address, a test run after a rebuild |
| Response | Call the control room and ask whether somebody is switching. Only then check the network path and the source. No automatic blocking, because intervening in a process network becomes a disturbance itself |
| Coverage | MITRE ATT&CK for ICS, technique group for manipulation of the process |
Rules like that come from three sources. From MITRE ATT&CK for ICS, from documented malware such as Industroyer, TRITON and PIPEDREAM, and from our own testing practice, because we know what traces an attack path leaves. Every rule is tested first on our own hardware in the lab. What does not fire there does not go into operation.
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.
Systems for detecting attacks
For operators of critical infrastructure, § 31 BSIG requires systems for detecting attacks, together with evidence to the BSI every three years. The duty arrived with the second IT security act and has sat in this place since the NIS2 implementation act. What is meant is not a product category that can be bought, but the combination of sensors, analysis, rules and the response to them.
An IT SIEM alone does not satisfy it. It does not decode Modbus, S7comm or IEC 60870-5-104 and does not know the plant's normal operation, and without that a valid command at the wrong time passes unnoticed. Detection in OT therefore rests on an OT IDS that reads the industrial protocols, and on anomaly detection against a baseline describing the settled state.
| What an assessor wants to see | Where it comes from |
|---|---|
| Which areas are observed at all | The zone model and the list of crossings that are read |
| What observes them | Sensors, the link into the SIEM, evidence that it does not act back on the process |
| What counts as suspicious | The use cases, with trigger, data source and response |
| What was actually detected | Evaluations from operation, not from planning |
| How it was answered | Playbooks and the records of cases worked |
| That it has been practised | The report of an exercise with assigned roles |
The evidence is therefore mostly a documentation task. What the regulator asks for falls out of a build that runs in an orderly way anyway. The response side includes the case where it turns serious, meaning incident response with forensics able to handle plants that must not be switched off.
When building a SOC is the right step
Three triggers usually lead here. The first is the duty to detect. For operators of critical infrastructure, § 31 BSIG requires systems for detecting attacks, together with evidence to the BSI every three years. That duty 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 Splunk, Elastic and Microsoft Sentinel. On the sensor side Claroty, Nozomi Networks, Microsoft Defender for IoT and OMICRON come in. Which platform it becomes is the client's decision. 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 the federally funded joint project FINESSE we developed intrusion detection for vehicle buses and diagnostic protocols, a security event centre for use on board, and extended MITRE ATT&CK by domains it did not cover, an extension we call VATT&EK. 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
It depends on where the reading happens. A passive TAP couples the signal out physically and has no effect back on the process. A mirror port runs through the switch CPU and can itself disturb it under load. For every transition we settle beforehand with those responsible for the plant what gets connected where.
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.